From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> |
Cc: | hackers(at)postgreSQL(dot)org (PostgreSQL Hackers) |
Subject: | Re: [HACKERS] bug with aggregates |
Date: | 1999-06-12 16:42:32 |
Message-ID: | 15478.929205752@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Massimo Dal Zotto <dz(at)cs(dot)unitn(dot)it> writes:
> dz=> select count(1) from my_table;
> pqReadData() -- backend closed the channel unexpectedly.
Further notes --- I find that you can get the same crash with no table
at all,
select count(1);
6.4.2 executes both queries --- but curiously enough, it produces "1"
regardless of the size of the table you mention, which is not surprising
when you look at its plan ... it optimizes out the scan of the table
entirely. But if you do
select a,count(1) from table group by a;
then you get a count of the number of rows in each group, which is more
or less what I'd expect. This behavior is not consistent with the
ungrouped case.
After a quick gander at the SQL spec, I see no evidence that either of
these queries is allowed by the spec. I'm inclined to think that
"select count(1);" ought to be disallowed and "select count(1) from
my_table;" ought to be treated the same as "select count(*) from
my_table;", like it is in the grouped case. Comments?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 1999-06-12 18:16:53 | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Previous Message | Tom Lane | 1999-06-12 16:21:21 | Re: [HACKERS] bug with aggregates |