Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .." - Mailing list pgsql-sql

From Tom Lane
Subject Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .."
Date
Msg-id 29030.1053113122@sss.pgh.pa.us
Whole thread Raw
In response to Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .."  (Mike Winter <mike.winter@frontlogic.com>)
List pgsql-sql
Mike Winter <mike.winter@frontlogic.com> writes:
> If the "IN (1, 2, 3, 6, ..., n)" clause is big enough, the
> database will actually throw an error saying "Recursive Depth
> Exceeded" or something similar and not complete the query.

Would it perhaps be saying "out of free buffers: time to abort!" ?
If so, you're probably running into this bug, which was introduced
(by me :-() in 7.3:
http://archives.postgresql.org/pgsql-hackers/2003-03/msg00939.php
There is a fix in place for 7.3.3.

> It looks to me like the query parser is recursively calling
> an index scan for each row in the 'IN' clause rather than just
> doing one index scan that it seems it should be.

It is performing one index search per target value, yes, but not
recursively.  That's what it's supposed to do.
        regards, tom lane


pgsql-sql by date:

Previous
From: Mike Winter
Date:
Subject: Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR
Next
From: "Dean Gibson (DB Administrator)"
Date:
Subject: JOIN vs. WHERE ... IN (subselect)