Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 27 May 2024 11:20:52 -0700
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Danil Anisimow <anisimow.d@gmail.com>,
	Andres Freund <andres@anarazel.de>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Comments on Custom RMGRs
Message-ID: <ZlTPBEbxhshxn9WC@paquier.xyz>
References: <0892cd00635c8bcd458de6d43d31cf61953da1b2.camel@j-davis.com>
 <CABm2Ma5Hi9PU_wWP0f=YFu9aDDdeSdX2+JFDL_oDH-QHgexsgg@mail.gmail.com>
 <727b0f3b48aec2a4f968bf11c6fa8ca6382b6cca.camel@j-davis.com>
 <CABm2Ma6avU5hkk7dd+G2oRNJZJtLOT=Yzeq6fb0v2rf7_YYp7g@mail.gmail.com>
 <beb9c43d6492ffc273d236e4b93270dfad035f2f.camel@j-davis.com>
 <CABm2Ma5Ww9M8DgFTCcASnMiPPVYU8cd_wGhHZ5YnoK5im6wT2g@mail.gmail.com>
 <22e756affaad88b77a52d67cb532ed2a544f2e36.camel@j-davis.com>
 <CA+TgmoZxvVXx809WhOcLNbUgAYYiLY+Y-o_gDpay6uTLwaJVyA@mail.gmail.com>
 <1e2256b744836aeb485c61954e9d8272f80141a0.camel@j-davis.com>
 <CA+TgmoZS++BBdyWxFv6k-UhzX=MGsqd8mu_80Z646-T=jYgW2g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="MjzJaJb5kI5yZguo"
Content-Disposition: inline
In-Reply-To: <CA+TgmoZS++BBdyWxFv6k-UhzX=MGsqd8mu_80Z646-T=jYgW2g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZlTPBEbxhshxn9WC%40paquier.xyz>
Precedence: bulk


--MjzJaJb5kI5yZguo
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 17, 2024 at 04:25:15PM -0400, Robert Haas wrote:
> On Fri, May 17, 2024 at 4:20=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wr=
ote:
>> 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.
>=20
> 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

--MjzJaJb5kI5yZguo
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmZUzwQACgkQnvQgOdby
QH2nuA/8DRVL+I+5di14LoJgwskLhGgzivEW5f/MDugVWQFw6gdHI2x4h4sWpsgb
yX6tl0BEYV3HZUfsATKcorxwBLA6jQZpIJrYcjlzEChhuyZr9Unn0FVIads76Shc
8k/o9zIonqihokLwFTxNdOuNxSbIl4t1vmidUcpfGR59TlNs0j1HZbYc7AF0GwL6
Vbw+t1JJZCQ+ib+LTEX4VcNwy/nQe4AiLedFgswvHAQ6TfI2baE4uCntqL9MLobJ
JR7AC/WYJ780NgwW1nmYqRnb5yHBJdfx9XNK3Kj7O6uG/RAaru5je/sd9pzrZREB
L1cjw+JUmXC345PBpkD7fy9Y2DmZam5aZeTDnt0hD4jKJk+ug0PGbBXnN3hZRcQy
stPdKqOFuZ/I5I/FJTcEA8RcuHu/4NiZbYsGZf8QPqofGjTZJaOACEAKiYz6XwrV
lf5wQ7I/Ksv6IabfyH1xVVcQzcO4FzsUj2ZidhJtH4svK+p+MdgjU4uIX0+H1c/I
Dzr3r/2YzqWHGSYoJoUNLTas41I6DFUgsYBvAcZJq6XJ6x8cC3/R1iJgui+ZBK5G
FQDf8efw3igu4Hh/HtpE8IEBcNv8xnrstOcpAOuvk70Z+kgAGSvCemRlyjcnnTtX
xZwVvcf30hLujvMVjpNhE+ERPowQcP4xUGmhMjfEhMcxu4A/aRE=
=PTzi
-----END PGP SIGNATURE-----

--MjzJaJb5kI5yZguo--