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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Russell Smith | 2007-08-23 07:42:28 | Re: Optimising "in" queries |
Previous Message | Michael Glaesemann | 2007-08-23 00:21:05 | Re: Optimising "in" queries |