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

Re: SELECT with MANY tables

From: Javier Carlos <fjcarlos(at)correo(dot)insp(dot)mx>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: SELECT with MANY tables
Date: 2003-11-26 19:42:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Quoting Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Javier Carlos <fjcarlos(at)correo(dot)insp(dot)mx> writes:
> >    When I make a SELECT with many tables (more than 12), postgresql eats
> all my
> > %CPU and I've waited more than 1 hour and stays the same. The weird thing
> is
> > that with 10 tables the same select with the same joins only takes about 5
> > seconds. First I thought that It was a problem related with one specific
> table,
> > but I've changed in the SELECT the tables and while the number of tables
> remains
> > less than 12 all is ok.
> Hm.  Are you using the default GEQO settings, or something custom?
> 			regards, tom lane

    I'm using the default GEQO settings:

#geqo = true
#geqo_threshold = 11
#geqo_effort = 1
#geqo_generations = 0
#geqo_pool_size = 0 
#geqo_selection_bias = 2.0

   Yesterday I solved the problem recreating the database and remigrating all
the information. I think that the problem was the pg_dumpall of PostgreSQL
7.3.4, maybe corrupted some indexes.



Instituto Nacional de Salud Pública
Evaluación Oportunidades - DataWeb


In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2003-11-26 20:55:10
Subject: Re: 7.4RC2 PANIC: insufficient room in FSM
Previous:From: Bruce MomjianDate: 2003-11-26 18:19:54
Subject: Re: Fwd: Solaris build of 7.4 problem with

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