Re: Nested Loop join being improperly chosen
От | David Rowley |
---|---|
Тема | Re: Nested Loop join being improperly chosen |
Дата | |
Msg-id | 2F2B8795E8584EEB97AF9FE82CA1D7A5@amd64 обсуждение исходный текст |
Ответ на | Nested Loop join being improperly chosen (Brad Ediger <brad@bradediger.com>) |
Ответы |
Re: Nested Loop join being improperly chosen
|
Список | pgsql-performance |
I had a similar problem here: http://archives.postgresql.org/pgsql-bugs/2008-07/msg00026.php Is the nested loop performing a LEFT join with yours? It's a little difficult to tell just from the query plan you showed. A work around for mine was to use a full outer join and eliminate the extra rows in the where clause. A bit of a hack but it changed a 2 min query into one that ran in under a second. Of course this is not helping with your problem but at least may trigger some more feedback. David. -----Original Message----- From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Brad Ediger Sent: 22 August 2008 16:26 To: pgsql-performance@postgresql.org Subject: [PERFORM] Nested Loop join being improperly chosen Hello, I'm having trouble with a Nested Loop being selected for a rather complex query; it turns out this is a pretty bad plan as the nested loop's row estimates are quite off (1 estimated / 1207881 actual). If I disable enable_nestloop, the query executes much faster (42 seconds instead of 605). The tables in the query have all been ANALYZEd just before generating these plans. Here are the plans with and without enable_nestloop: http://pastie.org/258043 The inventory table is huge; it currently has about 1.3 x 10^9 tuples. The items table has around 10,000 tuples, and the other tables in the query are tiny. Any ideas or suggestions would be greatly appreciated. Thanks! -- Brad Ediger
В списке pgsql-performance по дате отправления: