I thought that I had but I screwed up the addresses.
Here they are:
benparts=# explain select count(rdate),rdate from reading where
sensor_id in (1137,1138,1139,1140) group by rdate order by rdate desc
limit 1;
QUERY PLAN
--
array processing???
There are no arrays. What made you think there might be?
The table definition is:
benparts=# \d reading
Table "public.reading"
Column |Type |
Modifiers
---+---
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Stephen Davies wrote:
>> While superficially equivalent, I have always believed that IN (a,b,c)
>> executed faster than =a or =b or =c. Am I wrong for PostgreSQL?
> Older versions of Postgres translated IN (a, b, c) into an OR'ed list of
> equalities.
Stephen Davies wrote:
> Interesting semantics. I have never seen the IN syntax referred to as
> "array processing" before.
>
> I have always thought of array processing as the thing that vector
> processors such as Cray and ETA do/did.
>
> While superficially equivalent, I have always believed
Interesting semantics. I have never seen the IN syntax referred to as
"array processing" before.
I have always thought of array processing as the thing that vector
processors such as Cray and ETA do/did.
While superficially equivalent, I have always believed that IN (a,b,c)
executed faster th
Russell Smith wrote:
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.
I have just discovered that PG 8.2 will turn an
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
s
[Please don't top post as it makes the discussion more difficult to
follow.]
On Aug 22, 2007, at 18:30 , Stephen Davies wrote:
I have always thought of array processing as the thing that vector
processors such as Cray and ETA do/did.
(I've always heard that referred to as vector processing.
>>> On Tue, Aug 21, 2007 at 9:40 PM, in message
<[EMAIL PROTECTED]>, Stephen Davies <[EMAIL PROTECTED]>
wrote:
> Is there any way to make the "larger" queries more efficient?
People would be in a better position to answer that if you posted the table
structure and the results of EXPLAIN ANALYZE
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 pr
Stephen Davies wrote:
I have a PostgreSQL 8.2.4 table with some seven million rows.
The psql query:
select count(rdate),rdate from reading where sensor_id in
(1137,1138,1139) group by rdate order by rdate desc limit 1;
takes a few seconds but:
select count(rdate),rdate from reading where se
On 8/21/07, Stephen Davies <[EMAIL PROTECTED]> wrote:
> I have a PostgreSQL 8.2.4 table with some seven million rows.
>
> The psql query:
>
> select count(rdate),rdate from reading where sensor_id in
> (1137,1138,1139) group by rdate order by rdate desc limit 1;
>
> takes a few seconds but:
>
> sel
I have a PostgreSQL 8.2.4 table with some seven million rows.
The psql query:
select count(rdate),rdate from reading where sensor_id in
(1137,1138,1139) group by rdate order by rdate desc limit 1;
takes a few seconds but:
select count(rdate),rdate from reading where sensor_id in
(1137,1138,11
13 matches
Mail list logo
