Re: partitioning query planner almost always scans all tables - Mailing list pgsql-general

From Spiros Ioannou
Subject Re: partitioning query planner almost always scans all tables
Date
Msg-id CACKh8C_tMuvjQ9ZepRJ31Ke-fTLBdxqBsSLKbsoO2LvXUq-d_g@mail.gmail.com
Whole thread Raw
In response to Re: partitioning query planner almost always scans all tables  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: partitioning query planner almost always scans all tables
List pgsql-general

> EXPLAIN ANALYZE  SELECT * FROM measurement_events WHERE
> measurement_source_id='df86917e-8df0-11e1-8f8f-525400e76ceb' ORDER BY
> measurement_time DESC LIMIT 1;
>
> This seems to fail, scanning all tables. Do you think this can be improved
> at all ? The query plan of the above query is as follows:

The combination of sorting by measurement_source_id and limit
hinders constraint exclusion because the order of the column
across whole the inheritance is not known to planner. And the
below plan also dosn't show whether constraint exclusion worked
or not, by the same reason. But I suppose it worked.

It is ORDER BY measurement_time, not measurement_id, and measurement_time is used to create the partition. So the planner should know the correct order, but instead it seems to query tables in the wrong order.

pgsql-general by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: partitioning query planner almost always scans all tables
Next
From: Andrey Lizenko
Date:
Subject: temporary tables are logged somehow?