On Wed, 5 Mar 2025 at 14:30, Aleksander Alekseev
<aleksander@timescale.com> wrote:
>
> Hi,
>
> > I would like to discuss the introduction of a hook for evaluating the
> > selectivity of an expression when searching for an optimal query plan.
> > This topic has been brought up in various discussions, for example, in [1].
> >
> > [...]
>
> As I vaguely recall recent proposals like this ("Pluggable TOASTer" to
> name one) this approach was criticised.
Could you explain why you think the Pluggable TOASTer proposal was similar?
IIRC, the Pluggable TOASTer patch added hooks in specific types with
the intent to allow specific well-defined actions that were supposed
to be supported by each type to be implemented by an extension; where
"well-defined" does some heavy lifting for "practically, there's only
one way to implement this for each type". That was why my final
response for that patch was that the extensibility part didn't make
sense - if there's practically only a single implementation based on
the API, then why is there an API at all; let alone so deeply
ingrained in the type-specific functions?
The patch proposed here, however, does not look like that to me. As a
start, it doesn't require catalog changes for the hook to be used, and
isn't specific to a single type.
Kind regards,
Matthias van de Meent
