| From: | Matteo Beccati <php(at)beccati(dot)com> |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | ORDER BY and LIMIT not propagated on inherited tables / UNIONs |
| Date: | 2005-09-02 10:20:57 |
| Message-ID: | 43182789.4070307@beccati.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
I'm using inherited tables to partition some data which can grow very
large. Recently I discovered that a simple query that on a regular table
would use an index was instead using seq scans (70s vs a guessed 2s).
The well known query is:
SELECT foo FROM bar ORDER BY foo DESC LIMIT 1
(The same applies for SELECT MIN(foo) FROM bar using 8.1)
The query plan generated when running the query on a table which has
inheritance forces the planner to choose a seq_scan for each table.
Wouldn't be a good thing to also promote ORDER BYs and LIMITs to each
subscan (like WHERE does)?
I needed a quick solution, so I wrote a function which looks each
inherited table separately and my problem is partially solved, but I
think that a (hopefully) little change in the optimizer could be advisable.
Attached are some EXPLAIN ANALYZE outputs of my suggestion.
Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com
| Attachment | Content-Type | Size |
|---|---|---|
| order_limit_inheritance.txt | plain/text | 12.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alex Stapleton | 2005-09-02 11:18:22 | Re: Avoid using swap in a cluster |
| Previous Message | Richard Huxton | 2005-09-02 09:48:11 | Re: Update is more affected( taking more time) than Select |