| From: | Ravi Krishna <ravikrishna(at)mail(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, "Alex V(dot)" <in_flight(at)pclovers(dot)ru>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>, tgl <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Table partition with primary key in 11.3 |
| Date: | 2019-06-07 19:25:26 |
| Message-ID: | 85D9BEE6-DE40-45C4-AAE3-7F0CE8BAA17E@mail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
>
> I was thinking of asynchonously cleaning it up rather than blocking
> DROP/DETACH ... which means you need to keep state somewhere. I don't
> think blocking DROP/DETACH is valuable -- a global index that blocks
> DROP/DETACH until the index is clean serves no useful purpose. (You
> could think of a multi-step approach with internal transaction commits,
> similar to CIC, but you still need a plan to clean that up in case the
> server crashes during that operation.)
In Oracle if you have a global unique index and a partition is dropped, the index is marked invalid and needs to be rebuild.
IOW, an outage.
DB2's approach is better. When the partition is dropped, the index entries are marked for deletion and it starts a async
process of cleaning it up, which can run into several days if the dropped partition is large. But at least the table is online.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-06-07 19:36:05 | Re: Table partition with primary key in 11.3 |
| Previous Message | Lu, Dan | 2019-06-07 19:22:20 | RE: Postgres 10.7 Systemd Startup Issue |