> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > Tom, do you have a plan to make a back patch for 7.0.3?
>
> No, I don't. No time for it now.
>
> > I got a bug report from a user with a script to reproduce the
> > problem. Seems the backend consumes infinite memory.
>
> Not infinite, surely ;-) ... but possibly more than her kernel will
> allow. As a workaround, I'd suggest setting geqo_threshold smaller,
> perhaps 8 or 9. IIRC, the way to do that in 7.0 is
> set geqo='on=8';
> Not sure if it's possible to set up a system-wide default for that
> in 7.0.
Yes, I thought about geqo too. However, a standard geqo settings
didn't help. It still took 0:49 (7.0.2, 7.1 takes only ~3 seconds).
Then I set:
Pool_Size 128 Generations 10
and now the query takes only 5 seconds!
> BTW, the main reason planning this join in 7.0 is so slow is that
> all the options look exactly alike and so the planner has no reason to
> discard any paths. As soon as you create some indexes, load up some
> data and VACUUM, the symmetry would be broken and performance should
> improve (geqo or not). Or at least it'd usually be broken. Is it
> possible that all her tables are exactly the same size?
Yes. t_cyuubunrui has four rows, and the others has only a row.
--
Tatsuo Ishii
