From: | Michael Lewis <mlewis(at)entrata(dot)com> |
---|---|
To: | Thomas Kellerer <shammat(at)gmx(dot)net> |
Cc: | Postgres General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Suggestion: provide a "TRUNCATE PARTITION" command |
Date: | 2021-01-08 17:26:40 |
Message-ID: | CAHOFxGqp0MSfzLP14CbiazoDazJEQFFeQLYiDDxiryOSg+gR0g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer <shammat(at)gmx(dot)net> wrote:
> Michael Lewis schrieb am 08.01.2021 um 17:47:
> > > For me, it seems too easily error prone such that a single typo in
> > > the IN clause may result in an entire partition being removed that
> > > wasn't supposed to be targeted.
> >
> > I don't see how this is more dangerous then:
> >
> > delete from base_table
> > where partition_key in (...);
> >
> > which would serve the same purpose, albeit less efficient.
> >
> >
> > Delete has a rollback option, and you can dry-run to see impacted rows
> effectively. Truncate does not.
>
> TRUNCATE can be rolled back as well.
>
My apologies. There are other concerns with concurrent transactions, but
you are correct that it can be rolled back.
Still, no feedback on the effect that a truncate call is having on the DB
and may be doing more than intended fairly easily. I am not in the hackers
group so I couldn't say this feature would not be implemented. It just
seems unlikely given the philosophies of that group.
From | Date | Subject | |
---|---|---|---|
Next Message | Jack Orenstein | 2021-01-08 17:47:53 | Finding memory corruption in an extension |
Previous Message | legrand legrand | 2021-01-08 17:23:19 | Re: Suggestion: provide a "TRUNCATE PARTITION" command |