Re: Support tid range scan in parallel? - Mailing list pgsql-hackers

From Cary Huang
Subject Re: Support tid range scan in parallel?
Date
Msg-id 198f6e32f62.1dfec98c4003394.5930612108856513464@highgo.ca
Whole thread Raw
In response to Re: Support tid range scan in parallel?  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
 > The workers are ending their scan early because
 > heap_getnextslot_tidrange() returns false on the first call from the
 > parallel worker.

Hi David, thank you for the testing!

Yes, the previous v9 patch missed setting node->trss_mintid and
node->trss_maxtid, causing the parallel workers to exit early due to
heap_getnextslot_tidrange() returning false. 

With the attached v10 patch, the parallel leader and workers now
have to evaluate (TidRangeEval()) the given TID ranges and set them
via ExecTidRangeScanInitializeDSM(),
ExecTidRangeScanReInitializeDSM() and 
ExecTidRangeScanInitializeWorker().

To prevent the leader and the workers from calling heap_setscanlimits()
and trying to set phs_startblock and phs_numblock concurrently in
shared memory, I added a condition to only allow parallel
leader to set them. Since node->trss_mintid and node->trss_maxtid
reside in local memory, the workers still have to call heap_set_tidrange
() to have them set to return correct scan results:

# SET parallel_setup_cost TO 0;
# SET parallel_tuple_cost TO 0;

# select count(*) from test where ctid >=  '(10,10)' and ctid <= '(10000,10)';
  count
---------
 1848151
(1 row)

# SET max_parallel_workers_per_gather TO 0;
=# select count(*) from test where ctid >=  '(10,10)' and ctid <= '(10000,10)';
  count
---------
 1848151
(1 row)

thank you again!

Cary
Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Assert single row returning SQL-standard functions
Next
From: Merlin Moncure
Date:
Subject: Re: Assert single row returning SQL-standard functions