Quoting Michael Lewis :
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
On Fri, Jan 8, 2021 at 10:12 AM Thomas Kellerer 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 targe
What is interesting here with the TRUNCATE WHERE (and in the proposed
plpgsql) is to offer the end user a way to perform a transparent truncate or
delete totally independent of the partitioning scheme (if any, or even if it
has changed).
--
Sent from: https://www.postgresql-archive.org/PostgreSQ
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:
del
On Fri, Jan 8, 2021 at 9:38 AM Thomas Kellerer wrote:
> Michael Lewis schrieb am 08.01.2021 um 16:32:
> > On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer sham...@gmx.net>> wrote:
> >
> > Hello,
> >
> > I wonder if it made sense to add a "TRUNCATE PARTITION" command to
> Postgres?
> >
> >
Michael Lewis schrieb am 08.01.2021 um 16:32:
On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer mailto:sham...@gmx.net>> wrote:
Hello,
I wonder if it made sense to add a "TRUNCATE PARTITION" command to Postgres?
Especially during bulk loads it's more efficient to TRUNCATE a partition
On Fri, Jan 8, 2021 at 2:36 AM Thomas Kellerer wrote:
> Hello,
>
> I wonder if it made sense to add a "TRUNCATE PARTITION" command to
> Postgres?
>
> Especially during bulk loads it's more efficient to TRUNCATE a partition
> if I know I want to replace all rows, rather than doing a DELETE.
>
> Cu
legrand legrand schrieb am 08.01.2021 um 14:57:> maybe a naïve plpgsql as
proposed in
https://www.postgresql-archive.org/Partitionning-support-for-Truncate-Table-WHERE-td5933642.html
may be an answer
Yes I am aware of that (and that's what I have used so far) - I just thought it
would make li
Hello,
maybe a naïve plpgsql as proposed in
https://www.postgresql-archive.org/Partitionning-support-for-Truncate-Table-WHERE-td5933642.html
may be an answer
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
