Re: Parallel Bitmap Heap Scan reports per-worker stats in EXPLAIN ANALYZE

On Fri, 5 Jul 2024 at 12:52, David Rowley <dgrowleyml@gmail.com> wrote:
> I propose we change these to uint64 while causing churn in this area,
> probably as a follow-on patch.  I think a uint32 isn't wide enough as
> you could exceed the limit with rescans.

I wondered how large a query it would take to cause this problem.  I tried:

create table a (a int);
insert into a select x%1000 from generate_Series(1,1500000)x;
create index on a(a);
vacuum freeze analyze a;

set enable_hashjoin=0;
set enable_mergejoin=0;
set enable_indexscan=0;
set max_parallel_workers_per_gather=0;

explain (analyze, costs off, timing off, summary off)
select count(*) from a a1 inner join a a2 on a1.a=a2.a;

After about 15 mins, the trimmed output from Linux is:

 Aggregate (actual rows=1 loops=1)
   ->  Nested Loop (actual rows=2250000000 loops=1)
         ->  Seq Scan on a a1 (actual rows=1500000 loops=1)
         ->  Bitmap Heap Scan on a a2 (actual rows=1500 loops=1500000)
               Recheck Cond: (a1.a = a)
               Heap Blocks: exact=2250000000
               ->  Bitmap Index Scan on a_a_idx (actual rows=1500 loops=1500000)
                     Index Cond: (a = a1.a)

Whereas, on MSVC, due to sizeof(long) == 4, it's:

 Aggregate  (actual rows=1 loops=1)
   ->  Nested Loop  (actual rows=2250000000 loops=1)
         ->  Seq Scan on a a1  (actual rows=1500000 loops=1)
         ->  Bitmap Heap Scan on a a2  (actual rows=1500 loops=1500000)
               Recheck Cond: (a1.a = a)
               ->  Bitmap Index Scan on a_a_idx (actual rows=1500 loops=1500000)
                     Index Cond: (a = a1.a)

Notice the "Heap Blocks: exact=2250000000" is missing on Windows.
This is because it wrapped around to a negative value and
show_tidbitmap_info() only shows > 0 values.

I feel this is a good enough justification to increase the width of
those counters to uint64, so I'll do that too.

David