From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallelism and sorting |
Date: | 2015-11-25 00:44:24 |
Message-ID: | 56550468.7080206@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11/23/15 5:47 PM, Robert Haas wrote:
> 2. In Parallel Seq Scan, the determination of what page to scan next
> isn't dependent on the contents of any page previously scanned. In
> Parallel Index Scan, it is. Therefore, the amount of effective
> parallelism is likely to be less. This doesn't mean that trying to
> parallelize things here is worthless: one backend can be fetching the
> next index page while some other backend is processing the tuples from
> a page previously read.
Presumably we could simulate that today by asking the kernel for the
next page in advance, like we do for seqscans when
effective_io_concurrency > 1. My guess is a parallel worker won't help
there.
Where a parallel worker might provide a lot of benefit is separating
index scanning from heap scanning (to check visibility or satisfy a
filter). It wouldn't surprise me if a single worker reading an index
could keep a number of children busy retrieving heap tuples and
processing them. It might be nice if an index scan node just fired up
it's own workers and talked to them directly.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2015-11-25 00:46:56 | Re: Using quicksort for every external sort run |
Previous Message | Peter Geoghegan | 2015-11-25 00:33:19 | Re: Using quicksort for every external sort run |