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 isset geqo='on=8';
Not sure if it's possible to set up a system-wide default for that
in 7.0.
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?
regards, tom lane