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

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: BUG #17295: Different query plan with Index Only Scan and Bitmap Index Scan.
Дата
Msg-id aee23e3a-19dc-95da-34a3-d34e070e4294@enterprisedb.com
обсуждение исходный текст
Ответ на BUG #17295: Different query plan with Index Only Scan and Bitmap Index Scan.  (PG Bug reporting form <noreply@postgresql.org>)
Список 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



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Дмитрий Иванов
Дата:
Сообщение: Re: pg_restore depending on user functions
Следующее
От: Miles Delahunty
Дата:
Сообщение: table unreadable after altering related table embedded via a view