From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Danil Anisimow <anisimow(dot)d(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Comments on Custom RMGRs |
Date: | 2024-05-27 18:20:52 |
Message-ID: | ZlTPBEbxhshxn9WC@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote:
> On Fri, May 17, 2024 at 4:20 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> Regarding this particular change: the checkpointing hook seems more
>> like a table AM feature, so I agree with you that we should have a good
>> idea how a real table AM might use this, rather than only
>> pg_stat_statements.
>
> I would even be OK with a pg_stat_statements example that is fully
> working and fully explained. I just don't want to have no example at
> all. The original proposal has been changed twice because of
> complaints that the hook wasn't quite useful enough, but I think that
> only proves that v3 is closer to being useful than v1. If v1 is 40% of
> the way to useful and v3 is 120% of the way to useful, wonderful! But
> if v1 is 20% of the way to being useful and v3 is 60% of the way to
> being useful, it's not time to commit anything yet. I don't know which
> is the case, and I think if someone wants this to be committed, they
> need to explain clearly why it's the first and not the second.
Please note that I've been studying ways to have pg_stat_statements
being plugged in directly with the shared pgstat APIs to get it backed
by a dshash to give more flexibility and scaling, giving a way for
extensions to register their own stats kind. In this case, the flush
of the stats would be controlled with a callback in the stats
registered by the extensions, conflicting with what's proposed here.
pg_stat_statements is all about stats, at the end. I don't want this
argument to act as a barrier if a checkpoint hook is an accepted
consensus here, but a checkpoint hook used for this code path is not
the most intuitive solution I can think of in the long-term.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Bapat | 2024-05-27 18:27:05 | Re: Avoid possible dereference null pointer (src/backend/catalog/pg_depend.c) |
Previous Message | Ranier Vilela | 2024-05-27 17:51:04 | Re: Fix calloc check if oom (PQcancelCreate) |