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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Sketch of a fix for that truncation data corruption issue
Дата
Msg-id CAH2-Wzm_O9bU6+ux5Gofc1EhDFaBq4oya48gX=z-+jHhvGW5QQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sketch of a fix for that truncation data corruption issue  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Sketch of a fix for that truncation data corruption issue
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Sketch of a fix for that truncation data corruption issue