public inbox for [email protected]  

help / color / mirror / Atom feed
From: Jonathan S. Katz <[email protected]>
To: Robert Haas <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Justin Pryzby <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: [email protected]
Subject: Re: Should we remove vacuum_defer_cleanup_age?
Date: Fri, 14 Apr 2023 09:46:59 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoaZXaY_xJakDxZMeUUG+CuuuDmL+Yg8-LjPL5kiT-2Zjg@mail.gmail.com>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<ZDWLvS1GghESoX/[email protected]>
	<[email protected]>
	<CAA4eK1+s7hyed2ZSwTC42N6VqCV73CGtzBRfcf1qgjCSJbO3Gw@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CA+TgmoaZXaY_xJakDxZMeUUG+CuuuDmL+Yg8-LjPL5kiT-2Zjg@mail.gmail.com>

On 4/14/23 8:30 AM, Robert Haas wrote:
> On Thu, Apr 13, 2023 at 11:06 PM Laurenz Albe <[email protected]> wrote:
>> I am not against this in principle, but I know that there are people using
>> this parameter; see the discussion linked in
>>
>> https://postgr.es/m/[email protected]
>>
>> I can't say if they have a good use case for that parameter or not.
> 
> Yeah, I feel similarly. Actually, personally I have no evidence, not
> even an anecdote, suggesting that this parameter is in use, but I'm a
> bit skeptical of any consensus of the form "no one is using X,"
> because there sure are a lot of people running PostgreSQL and they
> sure do a lot of things. Some more justifiably than others, but often
> people have surprisingly good excuses for doing stuff that sounds
> bizarre when you first hear about it, and it doesn't seem totally
> impossible that somebody could have found a way to get value out of
> this.

Let me restate [1] in a different way.

Using a large enough dataset, I did qualitatively look at overall usage 
of both "vacuum_defer_cleanup_age" and compared to 
"hot_standby_feedback", given you can use both to accomplish similar 
outcomes. The usage of "vacuum_defer_cleanup_age" was really minimal, in 
fact approaching "0", whereas "hot_standby_feedback" had significant 
adoption.

I'm not saying that "we should remove a setting just because it's not 
used" or that it may not have utility -- I'm saying that we can remove 
the setting given:

1. We know that using this setting incorrectly (which can be done fairly 
easily) can cause significant issues
2. There's another setting that can accomplish similar goals that's much 
safer
3. The setting itself is not widely used

It's the combination of all 3 that led to my conclusion. If it were just 
(1), I'd lean more strongly towards trying to fix it first.

> However, I suspect that there aren't many such people, and I think the
> setting is a kludge, so I support removing it. Maybe we'll find out
> that we ought to add something else instead, like a limited delimited
> in time rather than in XIDs. Or maybe the existing facilities are good
> enough. But as Peter rightly says, XID age is likely a poor proxy for
> whatever people really care about, so I don't think continuing to have
> a setting that works like that is a good plan.

That seems like a good eventual outcome.

Thanks,

Jonathan

[1] 
https://www.postgresql.org/message-id/bf42784f-4d57-0a3d-1a06-ffac1a09318c%40postgresql.org



Attachments:

  [application/pgp-signature] OpenPGP_signature (840B, ../[email protected]/2-OpenPGP_signature)
  download

view thread (5+ messages)  latest in thread

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Should we remove vacuum_defer_cleanup_age?
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox