Re: severe performance issue with planner (fwd) - Mailing list pgsql-performance

I think i just sent an email out to the qrong person.. so if this ends up in
the list 2x i'm very sorry:

i changed the query to:SELECT
w8.wid,
w8.variant,
w8.num_variants,
sum_text(w8.unicode) as unicodes,
sum_text(w8.pinyin) as pinyins
FROM
words as w0 JOIN words as w1 ON(w1.wid = w0.wid AND w1.variant = w0.variant
AND w1.sequence = w0.sequence + 1 AND w1.pinyin LIKE 'fu_')
JOIN words as w2 ON(w2.wid = w1.wid AND w2.variant = w1.variant AND
w2.sequence = w1.sequence + 1 AND w2.pinyin LIKE 'ji_')
JOIN words as w3 ON(w3.wid = w2.wid AND w3.variant = w2.variant AND
w3.sequence = w2.sequence + 1 AND w3.pinyin LIKE 'guan_')
JOIN words as w4 ON(w4.wid = w3.wid AND w4.variant = w3.variant AND
w4.sequence = w3.sequence + 1 AND w4.pinyin LIKE 'kai_')
JOIN words as w5 ON(w5.wid = w4.wid AND w5.variant = w4.variant AND
w5.sequence = w4.sequence + 1 AND w5.pinyin LIKE 'fang_')
JOIN words as w6 ON(w6.wid = w5.wid AND w6.variant = w5.variant AND
w6.sequence = w5.sequence + 1 AND w6.pinyin LIKE 'xi_')
JOIN words as w7 ON(w7.wid = w6.wid AND w7.variant = w6.variant AND
w7.sequence = w6.sequence + 1 AND w7.pinyin LIKE 'tong_')
JOIN words as w8 ON(w8.wid = w7.wid AND w8.variant = w7.variant)
WHERE
w0.wid > 0 AND
w0.pinyin = 'zheng4' AND
w0.def_exists = 't' AND
w0.sequence = 0
GROUP BY
w8.wid,
w8.variant,
w8.num_variants,
w8.page_order,
w0.sequence ,
w1.sequence ,
w2.sequence ,
w3.sequence ,
w4.sequence ,
w5.sequence ,
w6.sequence ,
w7.sequence
ORDER BY
w8.page_order;


and this cuts the time from 2900ms to about 1200ms.  Is there any way to get
better time since the prepared statements for this explicit join query is
about 320ms...

thx so far guys



>
>Kris Jurka <books@ejurka.com> writes:
> > On Thu, 11 Mar 2004, Tom Lane wrote:
> >> "Eric Brown" <bigwhitecow@hotmail.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.
>
>The problem with this example is that it's a nine-way self-join.
>Ordinarily the planner can eliminate many possible join paths at low
>levels, because they are more expensive than other available options.
>But in this situation all the available options have *exactly the same
>cost estimate* because they are all founded on exactly the same statistics.
>The planner fails to prune any of them and ends up making a random
>choice after examining way too many alternatives.
>
>Maybe we should think about instituting a hard upper limit on the number
>of alternatives considered.  But I'm not sure what the consequences of
>that would be.  In the meantime, the answer for the OP is to arbitrarily
>limit the number of join orders considered, as described in the
>above-mentioned web page.  With the given query constraints there's
>really only one join order worth thinking about ...
>
> > 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?
>
>Selecting the GEQO planner doesn't really matter here, because it has
>no better clue about how to choose among a lot of alternatives with
>identical cost estimates.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 8: explain analyze is your friend

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar � get it now!
http://clk.atdmt.com/AVE/go/onm00200415ave/direct/01/