Tatsuo Ishii <[EMAIL PROTECTED]> 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. 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
- Re: [HACKERS] Idea for reducing planning tim... Alfred Perlstein
- Re: [HACKERS] Idea for reducing planning... Marc G. Fournier
- Re: [HACKERS] Idea for reducing planning time Tom Lane
- [HACKERS] Re: Idea for reducing planning time Bruce Momjian
- Re: [HACKERS] Idea for reducing planning time Tom Lane
- Re: [HACKERS] Idea for reducing planning time Bruce Momjian
- Re: [HACKERS] Idea for reducing planning time Tom Lane
- Re: [HACKERS] Idea for reducing planning tim... Bruce Momjian
- Re: [HACKERS] Idea for reducing planning tim... Tatsuo Ishii
- Re: [HACKERS] Idea for reducing planning... Tom Lane
- Re: [HACKERS] Idea for reducing pla... Tatsuo Ishii
- RE: [HACKERS] Idea for reducing planning time Mikheev, Vadim
- TOAST-table vacuuming (was Re: [HACKERS] Idea for re... Tom Lane
- Re: [HACKERS] Idea for reducing planning time Bruce Momjian
- Re: [HACKERS] Idea for reducing planning time Nathan Myers
- RE: [HACKERS] Idea for reducing planning time Mikheev, Vadim