Re: Optimising "in" queries
От | Russell Smith |
---|---|
Тема | Re: Optimising "in" queries |
Дата | |
Msg-id | 46CD3869.90600@pws.com.au обсуждение исходный текст |
Ответ на | Re: Optimising "in" queries (Michael Glaesemann <grzm@seespotcode.net>) |
Ответы |
Re: Optimising "in" queries
|
Список | 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
В списке pgsql-performance по дате отправления: