Re: improve transparency of bitmap-only heap scans

On Tue, Mar 10, 2020 at 12:15 PM David Steele <david@pgmasters.net> wrote:
>
> Hi Jeff,
>
> On 2/7/20 10:22 AM, Alexey Bashtanov wrote:
> > I've changed it all to "unfetched" for at least not to call the same
> > thing differently
> > in the code and in the output, and also rebased it and fit in 80 lines
> > width limit.
>
> What do you think of Alexey's updates?
>
> Regards,
> --
> -David
> david@pgmasters.net

I've added myself as a reviewer.

The patch looks good to me. It doesn't seem to have much risk either;
there are not spec concerns applicable (since it's EXPLAIN), and the
surface area for impact quite small. Both make check and check-world
pass.

Here's a test query setup I worked up:

create table exp(a int, d int);
insert into exp(a, d) select random() * 100, t.i % 50 from
generate_series(0,10000000) t(i);
create index index_exp_a on exp(a);
create index index_exp_d on exp(d);
analyze exp;

Then:
explain analyze select count(*) from exp where a = 25 and d between 5 and 10;
shows: Heap Blocks: exact=10518

but if I:
vacuum freeze exp;
then it shows: Heap Blocks: unfetched=10518
as I'd expect.

One question though: if I change the query to:
explain (analyze, buffers) select count(*) from exp where a between 50
and 100 and d between 5 and 10;
then I get a parallel bitmap heap scan, and I only see exact heap
blocks (see attached explain output).

Does the original optimization cover parallel bitmap heap scans like
this? If not, I think this patch is likely ready for committer. If so,
then we still need support for stats tracking and explain output for
parallel nodes.

I've taken the liberty of:
- Reformatting slightly for a cleaner diff.
- Running pgindent against the changes
- Added a basic commit message.
- Add unfetched_pages initialization to ExecInitBitmapHeapScan.

See attached.

Thanks,
James