Message-ID: <46CD3869.90600@pws.com.au>
Date: Thu, 23 Aug 2007 17:34:01 +1000
From: Russell Smith <mr-russ@pws.com.au>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Michael Glaesemann <grzm@seespotcode.net>
CC: Stephen Davies <scldad@sdc.com.au>,  pgsql-performance@postgresql.org
Subject: Re: Optimising "in" queries
References: <200708221210.36770.scldad@sdc.com.au>
	<46CC16F3.7060606@pws.com.au>
	<AAF53AEE-B98C-45BD-B80F-8FA528BFB98B@seespotcode.net>
In-Reply-To: <AAF53AEE-B98C-45BD-B80F-8FA528BFB98B@seespotcode.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael Glaesemann wrote:
> 
> On Aug 22, 2007, at 5:58 , Russell Smith wrote:
> 
>> Stephen Davies wrote:
>>> select count(rdate),rdate from reading where sensor_id in 
>>> (1137,1138,1139,1140) group by rdate order by rdate desc limit 1;
>>>
>>>
>> It would have been helpful to see the table definition here.  I can 
>> say up front that array processing in postgres is SLOW.
> 
> Um, what array processing are you seeing here? IN (a, b, b) is not an 
> array construct.

Filter: (sensor_id = ANY ('{1137,1138,1139,1140}'::integer[]))

I've never seen this plan item except for when array's are involved.  I 
could be wrong.  I'd like to know how this is generated when you don't 
have an array.

Regards

Russell Smith