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: | 1069875722.3fc5020a6cfd9@correo.insp.mx |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
>
Hi,
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.
Regards,
Javier
---------------------------------------
Instituto Nacional de Salud Pública
Evaluación Oportunidades - DataWeb
http://evaloportunidades.insp.mx
-------------------------------------------------
http://www.insp.mx
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-26 20:55:10 | Re: 7.4RC2 PANIC: insufficient room in FSM |
Previous Message | Bruce Momjian | 2003-11-26 18:19:54 | Re: Fwd: Solaris build of 7.4 problem with |