Re: Idea for reducing planning time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Idea for reducing planning time
Date: 2001-02-27 15:45:49
Message-ID: 29261.983288749@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-02-27 15:54:39 Re: SunOS4
Previous Message Oliver Elphick 2001-02-27 15:38:15 Re: COPY doesn't works when containing ' ' or ' ' characters on db