| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Manuel Rigger <rigger(dot)manuel(at)gmail(dot)com> |
| Subject: | Re: Broken defenses against dropping a partitioning column |
| Date: | 2019-07-08 17:18:10 |
| Message-ID: | CA+TgmoaOjCaDV7Xx6NFCRkpYLbWKidhN1dBbf=0UFByZWZvDSg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 8, 2019 at 11:08 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> FWIW, I was imagining the action as being (1) detach all the child
> partitions, (2) make parent into a non-partitioned table, (3)
> drop the target column in each of these now-independent tables.
> No data movement. Other than the need to acquire locks on all
> the tables, it shouldn't be particularly slow.
I see. I think that would be reasonable, but like you say, it's not
clear that it's really what users would prefer. You can think of a
partitioned table as a first-class object and the partitions as
subordinate implementation details; or you can think of the partitions
as the first-class objects and the partitioned table as the
second-rate glue that holds them together. It seems like users prefer
the former view.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexander Korotkov | 2019-07-08 18:09:22 | Re: [PATCH] kNN for btree |
| Previous Message | Robert Haas | 2019-07-08 16:52:05 | Re: tableam vs. TOAST |