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: severe performance issue with planner |
Date: | 2004-03-14 03:48:01 |
Message-ID: | Pine.BSO.4.56.0403132240261.491@leary.csoft.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2004-03-14 15:52:27 | Re: Drop Tables Very Slow in Postgresql 7.2.1 |
Previous Message | Mike Bridge | 2004-03-14 03:10:18 | Re: High CPU with 7.4.1 after running for about 2 weeks |