Re: vacuum_truncate configuration parameter and isset_offset

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Nikolay Shaplov <dhyan(at)nataraj(dot)su>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, Albe <laurenz(dot)albe(at)cybertec(dot)at>, Gurjeet Singh <gurjeet(at)singh(dot)im>, Will Storey <will(at)summercat(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: vacuum_truncate configuration parameter and isset_offset
Date: 2025-03-26 17:54:23
Message-ID: CAKFQuwb2_KrsduY6+ZcWri2ftNw6=EggAQVPrO630OaoANzAag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 26, 2025 at 10:29 AM Nikolay Shaplov <dhyan(at)nataraj(dot)su> wrote:

> The only thing I am asking for: please keep code consistent. Better keep
> reloption core the way it was, but if it is not possible, then keep it
> consistent then.
>

Consistency at the expense of all else is a debatable position that will
benefit from being actively justified. Incremental improvement has a lot
of merit. The cost of incremental improvement is quite low for generally
high benefit. Wholesale rewriting has a much higher cost for basically the
same benefit. That's a lot of added cost in order to stay "consistent", so
what are the added benefits of consistency for incurring that cost?

There is a baseline benefit to consistency that any incremental improvement
needs to overcome to be worthwhile. I don't think the isset_offset
implementation to handle this rare boolean option overcomes that baseline.
I've tossed my weight, expect others to do so as well, and we'll move
forward. But none of the positions proposed here are considered absolute
by the project.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2025-03-26 18:09:32 Re: making EXPLAIN extensible
Previous Message Robert Haas 2025-03-26 17:40:19 Re: Current master hangs under the debugger after Parallel Seq Scan (Linux, MacOS)