| From: | Craig James <craig_james(at)emolecules(dot)com> |
|---|---|
| To: | Joe Uhl <joeuhl(at)gmail(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Partitioned Tables and ORDER BY |
| Date: | 2009-10-19 17:16:27 |
| Message-ID: | 4ADC9EEB.4090500@emolecules.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Joe Uhl wrote:
> This seems like a pretty major weakness in PostgreSQL partitioning. I
> have essentially settled on not being able to do queries against the
> parent table when I want to order the results. Going to have to use a
> Hibernate interceptor or something similar to rewrite the statements so
> they hit specific partitions, will be working on this in the coming week.
>
> This weakness is a bummer though as it makes partitions a lot less
> useful. Having to hit specific child tables by name isn't much
> different than just creating separate tables and not using partitions at
> all.
I wonder if the "offset 0" trick would work here? I was told (for a different question) that the planner can't merge levels if there's an offset or limit on a subquery. So you might be able to do something like this:
select ... from (select ... offset 0) as foo order by ...
In other words, put your primary query as a sub-select without the sort criterion, with the "offset 0" as a sort of roadblock that the planner can't get past. Then the outer select does the sorting, without affecting the plan for the inner select.
Craig
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-10-19 17:36:15 | Re: Calculation of unused columns |
| Previous Message | Grzegorz Jaśkiewicz | 2009-10-19 16:13:38 | Re: Partitioned Tables and ORDER BY |