Re: BUG #17295: Different query plan with Index Only Scan and Bitmap Index Scan.

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: udv(dot)mail(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org, PG Bug reporting form <noreply(at)postgresql(dot)org>
Subject: Re: BUG #17295: Different query plan with Index Only Scan and Bitmap Index Scan.
Date: 2021-11-21 23:37:32
Message-ID: aee23e3a-19dc-95da-34a3-d34e070e4294@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

I'm not really sure which part you condides a bug? We simply don't
translate between IN() and OR-ed conditions, and there may be some
costing differences. So we may generate different plans, and the switch
between index scan and bitmap index scan may happen at different points.

On 11/20/21 17:52, PG Bug reporting form wrote:
>
> EXPLAIN SELECT * FROM t WHERE a IN (142,147,153,199);
> -- Bitmap Heap Scan on t (cost=3739.74..50987.74 rows=200000 width=8)
> |
> -- Recheck Cond: (a = ANY ('{142,147,153,199}'::integer[]))
> |
> -- -> Bitmap Index Scan on t_i (cost=0.00..3689.74 rows=200000
> width=0)|
> -- Index Cond: (a = ANY ('{142,147,153,199}'::integer[]))
> |

This is rather strange, though. Why would this have estimate 200000? The
other query has estimate 4, so it can't be because of missing stats etc.
Or why would it fix after several minutes?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Miles Delahunty 2021-11-22 02:44:37 table unreadable after altering related table embedded via a view
Previous Message Дмитрий Иванов 2021-11-21 15:30:16 Re: pg_restore depending on user functions