![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Please enter a FULL description of your problem: ------------------------------------------------- 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. |
#3
| |||
| |||
|
|
Quoting Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com>: On Mon, 24 Nov 2003, Javier Carlos wrote: Please enter a FULL description of your problem: ------------------------------------------------- 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. As a question, does the query work if you SET geqo=off; or SET geqo_threshold=<some higher number, say 20>? I tried with setting geqo=off and It didn't work. Then I set geqo_threshold=20, and neither. In both the result was: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. |
#4
| |||
| |||
|
|
On Mon, 24 Nov 2003, Javier Carlos wrote: Please enter a FULL description of your problem: ------------------------------------------------- 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. As a question, does the query work if you SET geqo=off; or SET geqo_threshold=<some higher number, say 20>? |
#5
| |||
| |||
|
|
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. |
#6
| |||
| |||
|
|
On Mon, 24 Nov 2003, Javier Carlos wrote: Quoting Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com>: On Mon, 24 Nov 2003, Javier Carlos wrote: Please enter a FULL description of your problem: ------------------------------------------------- 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. As a question, does the query work if you SET geqo=off; or SET geqo_threshold=<some higher number, say 20>? I tried with setting geqo=off and It didn't work. Then I set geqo_threshold=20, and neither. In both the result was: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. What does your postmaster log say? There should be something in there. I also forgot to ask for EXPLAIN output under normal conditions and with geqo off (although it's possible that it will fail as well for the latter) |
|
On Mon, 24 Nov 2003, Javier Carlos wrote: Quoting Stephan Szabo <sszabo (AT) megazone (DOT) bigpanda.com>: On Mon, 24 Nov 2003, Javier Carlos wrote: Please enter a FULL description of your problem: ------------------------------------------------- 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. As a question, does the query work if you SET geqo=off; or SET geqo_threshold=<some higher number, say 20>? I tried with setting geqo=off and It didn't work. Then I set geqo_threshold=20, and neither. In both the result was: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. What does your postmaster log say? There should be something in there. I also forgot to ask for EXPLAIN output under normal conditions and with geqo off (although it's possible that it will fail as well for the latter) |
#7
| |||
| |||
|
|
Javier Carlos <fjcarlos (AT) correo (DOT) insp.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 |
![]() |
| Thread Tools | |
| Display Modes | |
| |