Re: IN list processing performance (yet again)

From: Dave Tenny <tenny(at)attbi(dot)com>
To: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>
Cc: Bruno Wolff III <bruno(at)wolff(dot)to>, Andreas Pflug <Andreas(dot)Pflug(at)web(dot)de>, pgsql-performance(at)postgresql(dot)org
Subject: Re: IN list processing performance (yet again)
Date: 2003-05-29 12:48:41
Message-ID: 3ED601A9.50209@attbi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Christopher Kings-Lynne wrote:

>
>
>>Also, IN (subquery) is a known performance problem in PGSQL, at least if
>>
>>
>the subquery is going to return > many rows.
>
>
>>It's too bad, since I'm rather fond of subqueries, but I avoid them like
>>
>>
>the plague in PostgreSQL.
>
>You're not really using a subquery - really just a long list of integers.
>

Oops, you got that out of context, it was a different piece of
conversation about subqueries in IN predicate,
not the scalar forms that was my overall discussion point. You're
right, I'm using lists of integers,
someone else was suggesting using subqueries in some context and I was
responding to that.

>Subqueries are lightning fast, so long as you conver to the EXISTS form:
>
>SELECT * FROM tab WHERE id IN (SELECT id2 FROM tab2);
>
>converts to:
>
>SELECT * FROM tab WHERE EXISTS (SELECT id2 FROM tab2 WHERE id2=id);
>
>Chris
>
>
I hadn't thought of that, it's an excellent tip. I'll have to remember
it next time I want to use subqueries.
(Again, it's a side topic, my primary concern is scalar-form IN lists.)

Thanks,

Dave

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Schroeder 2003-05-29 13:58:07 Select query takes long to execute
Previous Message Bruno Wolff III 2003-05-29 10:55:31 Re: IN list processing performance (yet again)