On Wed, Feb 1, 2017 at 12:58 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> Yeah, I understand that point and I can see there is strong argument
> to do that way, but let's wait and see what others including Robert
> have to say about this point.
It seems to me that you can make an argument for any point of view.
In a parallel sequential scan, the smallest unit of work that can be
given to one worker is one heap page; in a parallel index scan, it's
one index page. By that logic, as Rahila says, we ought to do this
based on the number of index pages. On the other hand, it's weird to
use the same GUC to measure index pages at some times and heap pages
at other times, and it could result in failing to engage parallelism
where we really should do so, or using an excessively small number of
workers. An index scan that hits 25 index pages could hit 1000 heap
pages; if it's OK to use a parallel sequential scan for a table with
1000 heap pages, why is it not OK to use a parallel index scan to scan
1000 heap pages? I can't think of any reason.
On balance, I'm somewhat inclined to think that we ought to base
everything on heap pages, so that we're always measuring in the same
units. That's what Dilip's patch for parallel bitmap heap scan does,
and I think it's a reasonable choice. However, for parallel index
scan, we might want to also cap the number of workers to, say,
index_pages/10, just so we don't pick an index scan that's going to
result in a very lopsided work distribution.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
