RE: PQ - Can a set of slave processes be prevented from starting a rowrource scan if their result is bound to be discarded?

  • From: Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: ORACLE-L <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 24 Nov 2015 13:37:08 +0000



Yes, that's it - though I haven't checked it in the most recent versions of
Oracle.
The broadcast option is safe by comparison, of course, because every slave
realises that it has the whole (empty) result set.



Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________
From: Jure Bratina [jure.bratina@xxxxxxxxx]
Sent: 24 November 2015 13:35
To: Jonathan Lewis; ORACLE-L
Subject: Re: PQ - Can a set of slave processes be prevented from starting a
rowrource scan if their result is bound to be discarded?

Jonathan,

Thank you very much, that's a spot-on explanation. Just to be clear, if I
understand correctly, the implementation limitation/decision that is the cause
of this behaviour is that the slaves apparently don't notify the query
coordinator of how many rows they obtained during the scan of the build
rowsource and thus the query coordinator directs them to perform the scan of
the next rowsource unconditionally?

I'm asking that because I'm not sure I completely understand the statements:
"if the query were to run parallel they would need a mechanism that allowed
some synchronisation between slaves so that every slave could find out that
none of the slaves had received no rows from the first subquery, and this was
going to lead to hanging problems." and "But because the query is running in
parallel, a single slave that receives no data from the first tablescan cannot
assume that every other slave in the same set has also received no data –
there’s no cross-chat that allows the slaves to discover that every slave has
no data – so the second scan goes ahead."
The query coordinator probably still has to synchronize/direct all of the
slaves in the set scanning the build rowsource to wait till all of them finish
writing to the first table queue and only after that "synchronization point" it
directs them to start the scan of the second rowsource. So there is some
synchronization from the QC, but because it isn't aware that the previous scan
returned no rows, it directs the slaves to perform the scan of the second
rowsource. I hope I understood that correctly?

Thank you again and regards,
Jure Bratina

On Tue, Nov 24, 2015 at 1:06 PM, Jonathan Lewis
<jonathan@xxxxxxxxxxxxxxxxxx<mailto:jonathan@xxxxxxxxxxxxxxxxxx>> wrote:

Described and explained here:
https://jonathanlewis.wordpress.com/2014/02/28/empty-hash/


Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
________________________________


Other related posts: