Re: Query plan for "id IS NULL" on PK

On 2/14/23 15:04, Ben Chrobot wrote:
> Hello,
>
> Long time listener, first time caller.
>
> We have a large table (~470 million rows) with integer primary key id
> (not null) on a Postgres 14.5 cluster. A third-party tool is
> attempting to perform a SELECT-based full table copy in preparation
> for log-based sync with a query like the following:
>
> SELECT "id", "other_column_a", "other_column_b", "created_at",
> "updated_at"
> FROM "public"."my_large_table"
> WHERE (("id" > ? OR "id" IS NULL)) AND (("id" <= ?))
> ORDER  BY "id" LIMIT 50000;
>
> The lower bound increments by batch size (50k) while the upper bound
> is always the `max(id)`, in our case around 575,000,000.
>
> The query plan produced is very slow as the index condition does
> basically nothing:
>
>                         QUERY PLAN
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>  Limit  (cost=0.57..21901.46 rows=50000 width=417) (actual
> time=1708920.675..1709198.995 rows=50000 loops=1)
>    ->  Index Scan using my_large_table_pkey on
> my_large_table  (cost=0.57..135230792.97 rows=308733624 width=417)
> (actual time=1708920.673..1709195.926 rows=50000 loops=1)
>          Index Cond: (id <= 575187488)
>          Filter: ((id > 193208795) OR (id IS NULL))
>          Rows Removed by Filter: 157784540
>  Planning Time: 0.186 ms
>  Execution Time: 1709200.618 ms
> (7 rows)
> Time: 1709231.721 ms (28:29.232)
>
> We cannot change the query being executed. Is there any way we can
> make the query planner ignore `OR (id IS NULL)` (as that will never be
> the case for the PK) and use both `id` clauses in the index condition?
>
> We have provided the vendor with the same query without the `id is
> null` showing that it's significantly faster (see below). They have
> informed us that addressing the null check on a not null PK is on
> their roadmap to address but no timeline.
>
> explain analyze
> SELECT "id", "other_column_a", "other_column_b", "created_at",
> "updated_at"
> FROM "public"."my_large_table"
> WHERE (("id" > ?)) AND (("id" <= ?))
> ORDER  BY "id" LIMIT 50000;
>
> QUERY PLAN
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Limit (cost=0.57..13930.19 rows=50000 width=416) (actual
> time=2.118..400.937 rows=50000 loops=1)
> -> Index Scan using my_large_table_pkey on my_large_table
> (cost=0.57..85429173.84 rows=306645829 width=416) (actual
> time=2.117..398.325 rows=50000 loops=1)
> Index Cond: ((id > 193208795) AND (id <= 575187488))
> Planning Time: 0.166 ms
> Execution Time: 402.376 ms
>
> We have tried leading the planner to water with this view but it did
> not change the slow query plan:
>
> create view my_fast_large_table as
> select *
> from my_large_table
> where id is not null;
>
> Any other tricks to try here?
>
> Thank you,
> Ben Chrobot

When will id be null in a primary key?