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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2013-01-15 04:37:33 | Re: logical changeset generation v4 |
Previous Message | Gurjeet Singh | 2013-01-15 04:13:19 | Re: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT |