Re: Sketch of a fix for that truncation data corruption issue - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Sketch of a fix for that truncation data corruption issue
Date
Msg-id CAH2-Wzm_O9bU6+ux5Gofc1EhDFaBq4oya48gX=z-+jHhvGW5QQ@mail.gmail.com
Whole thread Raw
In response to Re: Sketch of a fix for that truncation data corruption issue  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Dec 11, 2018 at 12:39 PM Robert Haas <robertmhaas@gmail.com> wrote:
> How much have you considered the possibility that my rejection of that
> approach was a stupid and wrong-headed idea?  I'm not sure I still
> believe that not writing those buffers would have a meaningful
> performance cost.  Truncating relations isn't that common of an
> operation, and also, we could mitigate the impacts by having the scan
> that identifies the truncation point also write any dirty buffers
> after that point.

I too suspect that it would be okay to regress truncation. Certainly,
there are workloads that totally depend on truncation for reasonable
performance, but even that doesn't necessarily imply that it consumes
too many cycles. I'm okay with imposing costs on a minority workload
provided the benefit is there, and the penalty isn't that noticeable
in realistic scenarios, to real users.

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Sketch of a fix for that truncation data corruption issue
Next
From: Andres Freund
Date:
Subject: Re: Sketch of a fix for that truncation data corruption issue