MIME-Version: 1.0
References: <CANbhV-E4pTWeF-DsdaGsOrjJNFWPaR+Dstjrnkqvf9JFFgOKKQ@mail.gmail.com>
 <f781f8f198567cee9e3776487bab3e41a7b91b82.camel@j-davis.com>
 <20220512034010.4oqa76pasrulkw32@alap3.anarazel.de> <CANbhV-G7SfdRLR6r7sxY0uL=TRU0S=cxkWJGWyTdss3u8LFK=g@mail.gmail.com>
 <20220512234207.pwwp6q33f72byet2@alap3.anarazel.de> <CANbhV-FFgAFeNZ=qNc7Fr991Asym+sfj=R5hb02XeRE6067=hg@mail.gmail.com>
 <CABm2Ma7v4=W-1vH=kiA4M352F=Nd-Nvd_QBZufJ6EMGsS7Q-_A@mail.gmail.com>
 <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>
In-Reply-To: <22e756affaad88b77a52d67cb532ed2a544f2e36.camel@j-davis.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Fri, 17 May 2024 14:56:53 -0400
Message-ID: <CA+TgmoZxvVXx809WhOcLNbUgAYYiLY+Y-o_gDpay6uTLwaJVyA@mail.gmail.com>
Subject: Re: Comments on Custom RMGRs
To: Jeff Davis <pgsql@j-davis.com>
Cc: Danil Anisimow <anisimow.d@gmail.com>, Andres Freund <andres@anarazel.de>, 
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoZxvVXx809WhOcLNbUgAYYiLY%2BY-o_gDpay6uTLwaJVyA%40mail.gmail.com>
Precedence: bulk

On Fri, Mar 29, 2024 at 1:09=E2=80=AFPM Jeff Davis <pgsql@j-davis.com> wrot=
e:
> I am fine with this.
>
> You've moved the discussion forward in two ways:
>
>   1. Changes to pg_stat_statements to actually use the API; and
>   2. The hook is called at multiple points.
>
> Those at least partially address the concerns raised by Andres and
> Robert. But given that there was pushback from multiple people on the
> feature, I'd like to hear from at least one of them. It's very late in
> the cycle so I'm not sure we'll get more feedback in time, though.

In my seemingly-neverending pass through the July CommitFest, I
reached this patch. My comment is: it's possible that
rmgr_003.v3.patch is enough to be useful, but does anyone in the world
think they know that for a fact?

I mean, pgss_001.v1.patch purports to demonstrate that it can be used,
but that's based on rmgr_003.v2.patch, not the v3 patch, and the
emails seem to indicate that it may not actually work. I also think,
looking at it, that it looks much more like a POC than something we'd
consider ready for commit. It also seems very unclear that we'd want
pg_stat_statements to behave this way, and indeed "this way" isn't
really spelled out anywhere.

I think it would be nice if we had an example that uses the proposed
hook that we could actually commit. Maybe that's asking too much,
though. I think the minimum thing we need is a compelling rationale
for why this particular hook design is going to be good enough. That
could be demonstrated by means of (1) a well-commented example that
accomplishes some understandable goal and/or (2) a detailed
description of how a non-core table AM or index AM is expected to be
able to make use of this. Bonus points if the person providing that
rationale can say credibly that they've actually implemented this and
it works great with 100TB of production data.

The problem here is not only that we don't want to commit a hook that
does nothing useful. We also don't want to commit a hook that works
wonderfully for someone but we have no idea why. If we do that, then
we don't know whether it's OK to modify the hook in the future as the
code evolves, or more to the point, which kinds of modifications will
be acceptable. And also, the next person who wants to use it is likely
to have to figure out all on their own how to do so, instead of being
able to refer to comments or documentation or the commit message or at
least a mailing list post.

My basic position is not that this patch is a bad idea, but that it
isn't really finished. The idea is probably a pretty good one, but
whether this is a reasonable implementation of the idea doesn't seem
clear, at least not to me.

--=20
Robert Haas
EDB: http://www.enterprisedb.com