Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch

From: Robert Treat <rob(at)xzilla(dot)net>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Shayon Mukherjee <shayonj(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch
Date: 2025-05-08 18:23:28
Message-ID: CABV9wwOv7pV5SA9VQB3xONm2t8SPNZVNwrDsd5645Npte+bPzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 8, 2025 at 12:10 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
> I think it's better to simply disable the truncate work and perform it
> at a later time
> than introduce some new limit to how many times the truncation can be suspended.
> In the type of workload you are referring to, it is likely that the
> truncation will
> end up not completing, so why even try at all?
>

Yeah, I pretty much had the same thought; if you bail out after some
kind of cap, there will be workloads that will never complete the
truncate heap phase, in which case you should probably be using
truncate off. But the one thing I was a bit sympathetic on was how to
actually determine you are in this situation, or how bad the situation
was, in order to know that setting truncate off would help? To that
end, I wonder if it'd be worth adding the counter and printing that
information (and maybe elapsed time in this phase?) in vacuum verbose
output?

Robert Treat
https://xzilla.net

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-05-08 18:56:55 Re: Prolonged truncation phase during vacuum on toast table with repeated interruptions by lock waiters and a proposed POC patch
Previous Message Daniele Varrazzo 2025-05-08 17:38:36 Re: Fix PQport to never return NULL if the connection is valid