Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

Next:From: hubert depesz lubaczewskiDate: 2001-02-28 13:54:45
Subject: strange error
Previous:From: Peter SchindlerDate: 2001-02-28 11:05:04
Subject: Re: stuck spinlock

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group