Re: Sketch of a fix for that truncation data corruption issue

On Tue, Dec 11, 2018 at 12:39 PM Robert Haas <robertmhaas(at)gmail(dot)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