Skip site navigation (1) Skip section navigation (2)

Re: Optimising "in" queries

From: Russell Smith <mr-russ(at)pws(dot)com(dot)au>
To: Michael Glaesemann <grzm(at)seespotcode(dot)net>
Cc: Stephen Davies <scldad(at)sdc(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Optimising "in" queries
Date: 2007-08-23 07:34:01
Message-ID: 46CD3869.90600@pws.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
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

In response to

Responses

pgsql-performance by date

Next:From: Russell SmithDate: 2007-08-23 07:42:28
Subject: Re: Optimising "in" queries
Previous:From: Michael GlaesemannDate: 2007-08-23 00:21:05
Subject: Re: Optimising "in" queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group