Re: severe performance issue with planner (fwd)

From: Kris Jurka <books(at)ejurka(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: severe performance issue with planner (fwd)
Date: 2004-03-17 07:33:44
Message-ID: Pine.BSO.4.56.0403170230590.26091@leary.csoft.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


I sent this message to the list and although it shows up in the archives,
I did not receive a copy of it through the list, so I'm resending as I
suspect others did not see it either.

---------- Forwarded message ----------
Date: Sat, 13 Mar 2004 22:48:01 -0500 (EST)
From: Kris Jurka <books(at)ejurka(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Eric Brown <bigwhitecow(at)hotmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] severe performance issue with planner

On Thu, 11 Mar 2004, Tom Lane wrote:

> "Eric Brown" <bigwhitecow(at)hotmail(dot)com> writes:
> > [ planning a 9-table query takes too long ]
>
> See http://www.postgresql.org/docs/7.4/static/explicit-joins.html
> for some useful tips.
>

Is this the best answer we've got? For me with an empty table this query
takes 4 seconds to plan, is that the expected planning time? I know I've
got nine table queries that don't take that long.

Setting geqo_threshold less than 9, it takes 1 second to plan. Does this
indicate that geqo_threshold is set too high, or is it a tradeoff between
planning time and plan quality? If the planning time is so high because
the are a large number of possible join orders, should geqo_threhold be
based on the number of possible plans somehow instead of the number of
tables involved?

Kris Jurka

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shridhar Daithankar 2004-03-17 07:46:37 A good article about application tuning
Previous Message Joe Conway 2004-03-17 05:18:27 Re: rapid degradation after postmaster restart