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.
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 |