Re: Idea for reducing planning time

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Idea for reducing planning time
Date: 2001-02-28 13:00:05
Message-ID: 20010228220005G.t-ishii@sra.co.jp
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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message hubert depesz lubaczewski 2001-02-28 13:54:45 strange error
Previous Message Peter Schindler 2001-02-28 11:05:04 Re: stuck spinlock