On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I had some offlist discussion with Robert about the above point and we > feel that keeping only heap pages for parallel computation might not > be future proof as for parallel index only scans there might not be > any heap pages. So, it is better to use separate GUC for parallel > index (only) scans. We can have two guc's > min_parallel_table_scan_size (8MB) and min_parallel_index_scan_size > (512kB) for computing parallel scans. The parallel sequential scan > and parallel bitmap heap scans can use min_parallel_table_scan_size as > a threshold to compute parallel workers as we are doing now. For > parallel index scans, both min_parallel_table_scan_size and > min_parallel_index_scan_size can be used for threshold; We can > compute parallel workers both based on heap_pages to be scanned and > index_pages to be scanned and then keep the minimum of those. This > will help us to engage parallel index scans when the index pages are > lower than threshold but there are many heap pages to be scanned and > will also allow keeping a maximum cap on the number of workers based > on index scan size.
What about parallel CREATE INDEX? The patch currently uses min_parallel_relation_size as an input into the optimizer's custom cost model. I had wondered if that made sense. Note that another such input is the projected size of the final index. That's the thing that increases at logarithmic intervals as there is a linear increase in the number of workers assigned to the operation (so it's not the size of the underlying table). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers