| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Matthew Wakeling <matthew(at)flymine(dot)org> |
| Cc: | Jean-Michel Pouré <jmpoure(at)free(dot)fr>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Order by (for 15 rows) adds 30 seconds to query time |
| Date: | 2009-12-02 13:46:50 |
| Message-ID: | 4B166FCA.50507@postnewspapers.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2/12/2009 7:08 PM, Matthew Wakeling wrote:
> On Tue, 1 Dec 2009, Jean-Michel Pouré wrote:
>> PostgreSQL query analyzer needs to run a couple of times before it can
>> rewrite and optimize the query. Make sure demand_id, id and join IDs
>> carry indexes.
>
> Huh? At what point does the planner carry over previous plans and use
> them to further optimise the query?
>
> But perhaps the biggest factor here is calling a five table join a
> "pretty simple query".
Some of those tables are views composed of multiple unions, too, by the
looks of things.
Doesn't the planner have some ... issues ... with estimation of row
counts on joins over unions? Or is my memory just more faulty than usual?
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurent Laborde | 2009-12-02 15:32:44 | Re: Cost of sort/order by not estimated by the query planner |
| Previous Message | Laurent Laborde | 2009-12-02 13:20:30 | Re: Cost of sort/order by not estimated by the query planner |