Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 29 Aug 2024 09:28:46 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jeff Davis <pgsql@j-davis.com>, Robert Haas <robertmhaas@gmail.com>,
	"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: allowing extensions to control planner behavior
Message-ID: <Zs_AvjO-U-Z9AdcL@paquier.xyz>
References: <CA+TgmoZY+baV-T-5ifDn6P=L=aV-VkVBrPmi0TQkcEq-5Finww@mail.gmail.com>
 <95e423ea042a8d2f85c76ee28feb7a5b10265f4d.camel@j-davis.com>
 <CA+TgmoY4yBRawLY-u0GM6aW7f0N4W8RU8WsZRb5+qhpWWfmZcQ@mail.gmail.com>
 <646c3d09475e49a5d1145c91af0ce3fdc3cdee96.camel@j-davis.com>
 <3496381.1724887559@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="XNyECpL+bTpJiwIq"
Content-Disposition: inline
In-Reply-To: <3496381.1724887559@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/Zs_AvjO-U-Z9AdcL%40paquier.xyz>
Precedence: bulk


--XNyECpL+bTpJiwIq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 28, 2024 at 07:25:59PM -0400, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > Beyond awkwardness, one case where it matters is the interaction
> > between an extension that provides hints and an extension that offers a
> > CustomScan. How is the hints extension supposed to disable a path it
> > doesn't know about?

pg_hint_plan documents its hints here:
https://pg-hint-plan.readthedocs.io/en/master/hint_list.html#hint-list

Hmm.  I think that we should be careful to check that this works
correctly with pg_hint_plan, at least.  The module goes through a lot
of tweaks and is a can of worms in terms of plan adjustments because
we can only rely on the planner hook to do the whole work.  This leads
to a lot of frustration for users because each feature somebody asks
for leads to just more tweaks to apply on the paths.

The bullet list sent here sounds pretty good to me:
https://www.postgresql.org/message-id/3131957.1724789735@sss.pgh.pa.us

> This does not seem remarkably problematic to me, given Robert's
> proposal of a bitmask of allowed plan types per RelOptInfo.
> You just do something like
>=20
> 	rel->allowed_plan_types =3D DESIRED_PLAN_TYPE;
>=20
> The names of the bits you aren't setting are irrelevant to you.

For the types of scans to use, that would be OK.  The module has a
feature where one can also have a regex to match for an index, and
the module is very funky with inheritance and partitioned tables.

How does that help if using a Leading hint to force a join order?
That's something people like a lot.  But perhaps that's just the part
of upthread where we'd need a extra hook?  I am not completely sure to
get the portion of the proposal for that.  add_paths_to_joinrel() has
been mentioned, and there is set_join_pathlist_hook already there.
--
Michael

--XNyECpL+bTpJiwIq
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmbPwL4ACgkQnvQgOdby
QH2yBQ//RGs7Uupd06ddrZqgxkPRRqXeo0spiyT0BIRu2eKv2fgOJ5gBLo8bk2Y3
p4D6FvNSgO9xO4/csgnQBcCd1gUyEmO6FGkFrsM40buvXagpc4M2t81SuY1kYFBe
q9ofadvl359Jm+jO0t0+f/prxWrv+U+5KrZmpJVfO0HaX/jsHXFyAltTCOpKR2am
r64No29hK/tAHviiJBmFm1m+XMtpW1ZM+ZM+t++2PHevHd/rQzCGArlizPPya0OB
KgEmzh0Jz1ubl1nDIl2iCCTdA+j4TOz7kfiOVWdjennnHv8vjaZvHRECbrripWM3
T/gv2rnnzm5VKncQ73yi/nxhTt2YKM+X7RSxtMBbTLTOnXnRrP2f9R97hpO+nq3Y
IKMvvIqP6OkvfGyXbuzos5UpOb9wO8aN9aCfQ27qhuEayEAyYttMgrrg30uclueW
l0HbY12IWWgGjXyign33zpQhKbC5OCJ6NNrNtfrqxXQPN+4QBhDG8fHdbpTLCw5r
GyeMQWKA2oarR6n/CyepXD3M/FStmi9cik6Xc7s0+sJprfWNaxuWDe8pjmWe080W
I2zeJ5iAZ+kgiUI6tlBqN2xdw5UBr0mwYlSwLQO5Qfc73jWnTt8KRUV4MI7Y0hzc
ACDb9kjeYW9Y9ARw9WOrCecBRQpJjc8KgVdsWKEIR1MZ0bNRwuk=
=zscY
-----END PGP SIGNATURE-----

--XNyECpL+bTpJiwIq--