Re: partitioning query planner almost always scans all tables

From: Spiros Ioannou <sivann(at)inaccess(dot)com>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: partitioning query planner almost always scans all tables
Date: 2015-01-22 11:13:37
Message-ID: CACKh8C_tMuvjQ9ZepRJ31Ke-fTLBdxqBsSLKbsoO2LvXUq-d_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrey Lizenko 2015-01-22 14:06:03 temporary tables are logged somehow?
Previous Message Kyotaro HORIGUCHI 2015-01-22 11:07:30 Re: partitioning query planner almost always scans all tables