| From: | Ravi Krishna <srkrishna(at)yahoo(dot)com> |
|---|---|
| To: | |
| Cc: | "pgsql-generallists(dot)postgresql(dot)org pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: explain plan difference |
| Date: | 2019-11-04 15:00:27 |
| Message-ID: | 3FD70F49-80F9-4231-8D10-DD84148F2CC6@yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
>
> Never, unless you drop and recreate the table. Removing a dropped
> column would change the attnums of following columns, which we
> can't support because the tableoid+attnum is the only persistent
> identifier of a column.
>
> (From memory, operations like VACUUM FULL and CLUSTER will rewrite
> dropped columns with NULLs to reduce their storage impact. But they
> don't go away.)
>
>
Thank you. I remember reading it here that VACUUM FULL does what you describe above.
So even TRUNCATE does not help here?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-11-04 15:05:09 | Re: v12 and pg_restore -f- |
| Previous Message | Alvaro Herrera | 2019-11-04 14:53:36 | Re: v12 and pg_restore -f- |