Re: Improving scalability of Parallel Bitmap Heap/Index Scan

>>> On this note, there has been a proposed (but as far as I know untested)
>>> patch to speed up this sort in a much simpler way, in this thread
>>>
>>> https://www.postgresql.org/message-id/
>>> CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com
>>> <https://www.postgresql.org/message-id/
>>> CA%2BhUKGKztHEWm676csTFjYzortziWmOcf8HDss2Zr0muZ2xfEg%40mail.gmail.com>
>>>
>>> where you may find this patch
>>>
>>> https://www.postgresql.org/message-id/attachment/120560/0007-Specialize-
>>> pagetable-sort-routines-in-tidbitmap.c.patch <https://
>>> www.postgresql.org/message-id/attachment/120560/0007-Specialize-
>>> pagetable-sort-routines-in-tidbitmap.c.patch>
>>
>> Thanks for the pointer. I've applied that change to my patch set. See
>> other mail. It helped a lot further reducing the sort time in each
>> parallel worker.
>
> If that's the case, let's get that piece in committable shape first.
> That will make sure PG20 gets some improvement regardless of what
> happens with your other proposal, and allows us to isolate the effect
> of the proposed architectural change.
Attached is the patch for using sort_template.h in TIDBitmap based on
master. No other parallel BIS changes.

Here is a small test to show the gains. The relative savings increase
the more workers are used because the sorting is done serially.

create table test(col0 bigint, col1 bigint, filler char(5000));
insert into test select a, (random()*10000000)::bigint, 'test' from
generate_series(1, 10000000) a;
create index on test(col1);
vacuum analyze test;
set cpu_operator_cost = 2;
set max_parallel_workers_per_gather = 8;
explain analyze select count(col0) from test where col1 < 1000000;

Results (best of 5, settings for stable results enabled):

master: ~886 ms
patched: ~811 ms

The query plans are attached. The startup time of the parallel BHS
reduces significantly, which is were the serial sort takes place.

--
David Geier