Re: Bitmap scan seem like such a strange choice when "limit 1"

Поиск
Список
Период
Сортировка
От Klaudie Willis
Тема Re: Bitmap scan seem like such a strange choice when "limit 1"
Дата
Msg-id dtW7dvsuov1mKu9LRywm0_Ax00ES--hEviwZsEMkAJ5l-Q60eWXLTJaKEoXCHfPYYvboJpn1Ig785HAB_6R3dDrneO-_pAtFYwTZx3nTdjI=@protonmail.com
обсуждение исходный текст
Ответ на Re: Bitmap scan seem like such a strange choice when "limit 1"  (Laurenz Albe <laurenz.albe@cybertec.at>)
Ответы Re: Bitmap scan seem like such a strange choice when "limit 1"  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
> PostgreSQL estimates that 2817675 rows satisfy the index condition and expects
> that it will have to scan many of them before it finds one that satisfies the
> filter condition. That turns out to be a wrong guess.
>
> You could create an index on (cars_ref, t), then PostgreSQL will certainly
> pick an index scan.


Thanks!  But, the t (time constraint) already isolates a particular partition.  The bigtable is partitioned on exactly
t,by year.  This is why you do not see any other indexes/partitions being queried in the EXPLAIN. 

...
PARTITION BY RANGE (t)
...
CREATE TABLE public.bigtable_y2020 PARTITION OF public.bigtable
    FOR VALUES FROM ('2020-01-01 00:00:00') TO ('2021-01-01 00:00:00');

To me, it seems like filter on date is unnecessary when you already IS on such a partition!

I'd like to add, that when I do the same query DIRECTLY on the bigtable_y2020 (instead of the partition parent) it does
changeto "index scan" again. 

best regards
K




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

Предыдущее
От: Laurenz Albe
Дата:
Сообщение: Re: Bitmap scan seem like such a strange choice when "limit 1"
Следующее
От: Rich Shepard
Дата:
Сообщение: Check for duplicates before inserting new rows