On Wed, Feb 8, 2017 at 10:33 PM, Amit Kapila <amit.kapila16@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