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

Re: count(*) of zero rows returns 1

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Johnston <polobo(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: count(*) of zero rows returns 1
Date: 2013-01-15 04:18:19
Message-ID: CABwTF4UwWebbZ-FxKjoinz4hD0hbE_1AsMp8xY0Gv=97tOniHQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jan 14, 2013 at 11:03 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com>wrote:

> Gurjeet Singh escribió:
>
> > Interesting to note that SELECT * FROM table_with_zero_cols does not
> > complain of anything.
> >
> > postgres=# select * from test1;
> > --
> > (0 rows)
> >
> > This I believe result of the fact that we allow user to drop all columns
> of
> > a table.
> >
> > On a side note, Postgres allows me to do this (which I don't think is a
> bug
> > or useless): I inserted some rows into a table, and then dropped the
> > columns. The resulting table has no columns, but live rows.
> >
> > postgres=# select * from test_0_col_table ;
> > --
> > (200000 rows)
>
> Yeah.
>
> alvherre=# create table foo ();
> CREATE TABLE
> alvherre=# insert into foo default values;
> INSERT 0 1
> alvherre=# insert into foo default values;
> INSERT 0 1
> alvherre=# insert into foo default values;
> INSERT 0 1
> alvherre=# insert into foo default values;
> INSERT 0 1
> alvherre=# insert into foo select * from foo;
> INSERT 0 4
> alvherre=# insert into foo select * from foo;
> INSERT 0 8
> alvherre=# insert into foo select * from foo;
> INSERT 0 16
> alvherre=# insert into foo select * from foo;
> INSERT 0 32
> alvherre=# insert into foo select * from foo;
> INSERT 0 64
> alvherre=# select count(*) from foo;
>  count
> -------
>    128
> (1 fila)
>
> alvherre=# select * from foo;
> --
> (128 filas)
>
> If you examine the ctid system column you can even see that those empty
> rows consume some storage space.


I was trying to build a case and propose that we issue a TRUNCATE on the
table after the last column is dropped. But then realized that the rows may
have become invisible, but they can be brought back to visibility by simply
adding a new column. These rows with get the new column's DEFAULT value
(NULL by default), and then the result of a SELECT * will show all the rows
again.

-- 
Gurjeet Singh

http://gurjeet.singh.im/

In response to

pgsql-hackers by date

Next:From: Mark KirkwoodDate: 2013-01-15 04:37:33
Subject: Re: logical changeset generation v4
Previous:From: Gurjeet SinghDate: 2013-01-15 04:13:19
Subject: Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT

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