On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer <shammat@gmx.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.