From: | Brad Ediger <brad(at)bradediger(dot)com> |
---|---|
To: | "David Rowley" <dgrowley(at)gmail(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Nested Loop join being improperly chosen |
Date: | 2008-08-28 23:22:19 |
Message-ID: | 62A18AAC-9BD9-41FF-AA4F-794D9AB540C6@bradediger.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Aug 28, 2008, at 6:01 PM, David Rowley wrote:
> 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.
Hi David,
Thanks for your input. All of the joins are inner joins; the query is
a large one with 5 or 6 subqueries. It was being generated from a
popular data warehousing / business intelligence product whose name I
shall not mention. The vendor ended up pulling the subselects out into
SELECT INTO statements on temporary tables. It's kludgey, but it works
much better.
Thanks,
Brad
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2008-08-29 01:11:50 | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |
Previous Message | david | 2008-08-28 23:08:24 | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |