pg_qualstat can failed to group all constant values together

[dblugeon]

Hello Dalibo Team,

I think that I found an issue with pg_qualstat. I attach a scripted test and this result at the end.

When a query use one or more indexes, pgqualstat does not provide qualid or uniquequalid. This absence seems impact the result in powa-web. Powa-web can't create explain plan because argument array is not full (we can see it with pg_qualstat_by_query).

The problem occurs when there is an index. No problem with a primary key or without indexes.

script to reproduce this issue. test_pgqual_sql.txt

the result on my postgres result.txt result_pk.txt

Regards

[rjuju]

Hello,

Nice catch!

Actually, the problems is that a plan containing Bitmap Index Scan on a first qual and Bitmap Heap Scan with a filter on another qual won't consider the two quals as belonging to the same one.

For some obscure reason, pg prefer to do a Bitmap Index Scan for the 1st test case (with default parameters), and an Index Scan for the second one, explaining the difference.

FTR, the problematic case in your provided test case (thanks a lot) is:

                               QUERY PLAN                                
═════════════════════════════════════════════════════════════════════════
 Bitmap Heap Scan on test  (cost=4.21..14.39 rows=1 width=24)
   Recheck Cond: (a = 0)
   Filter: (b = 1)
   ->  Bitmap Index Scan on test_a_idx  (cost=0.00..4.21 rows=8 width=0)
         Index Cond: (a = 0)

@rdunklau It looks like for Bitmap Heap Scan, we need to save the qual information related to the filter in the context and compute both while handling the lefttree? Also, I don't think that pg_qualstats does handle the recheck cond (or maybe compute it for the filter instead), which will probably give broken stats for any lossy bitmap.