Re: Idea for reducing planning time

> 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