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
wrote:
Described and explained here:
https://jonathanlewis.wordpress.com/2014/02/28/empty-hash/
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
@jloracle
------------------------------