From: | Klaudie Willis <Klaudie(dot)Willis(at)protonmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bitmap scan seem like such a strange choice when "limit 1" |
Date: | 2020-09-04 13:01:34 |
Message-ID: | dtW7dvsuov1mKu9LRywm0_Ax00ES--hEviwZsEMkAJ5l-Q60eWXLTJaKEoXCHfPYYvboJpn1Ig785HAB_6R3dDrneO-_pAtFYwTZx3nTdjI=@protonmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 change to "index scan" again.
best regards
K
From | Date | Subject | |
---|---|---|---|
Next Message | Rich Shepard | 2020-09-04 13:21:10 | Check for duplicates before inserting new rows |
Previous Message | Laurenz Albe | 2020-09-04 12:14:15 | Re: Bitmap scan seem like such a strange choice when "limit 1" |