Re: Hook for Selectivity Estimation in Query Planning - Mailing list pgsql-hackers

From Aleksander Alekseev
Subject Re: Hook for Selectivity Estimation in Query Planning
Date
Msg-id CAJ7c6TN2P+C9vvr700Usb6nJJz58edajkKN1hnz2XDvyow3K3g@mail.gmail.com
Whole thread Raw
In response to Re: Hook for Selectivity Estimation in Query Planning  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: Hook for Selectivity Estimation in Query Planning
List pgsql-hackers
Andrei, Matthias,

> Could you explain why you think the Pluggable TOASTer proposal was similar?
> [...]

I merely pointed out that adding hooks without any particular value
for the Postgres users was criticized before, see for instance:

https://www.postgresql.org/message-id/20230206104917.sipa7nzue5lw2e6z%40alvherre.pgsql

One could argue - but wait, isn't TAM for instance just a bunch of
hooks in a nutshell? How do we distinguish a well-documented and more
or less stable API for the extension authors from a random hook put in
a convenient place? That's a good question. I don't have an answer to
it. This being said, the proposed patch doesn't strike me as a good or
documented API, or the one that is going to be stable in the long run.

> [...]
>
> Overall, I see that new hooks allow new [sometimes] open-source projects
> and startups to emerge - not sure about enterprises' benefits.
> Therefore, I'm not convinced by your current justification. Are there
> any technical objections?

There is no point in debating about good and evil or right and wrong.
The only important question is whether there will be a committer
willing to accept the proposed change considering its controversy.

-- 
Best regards,
Aleksander Alekseev



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: track generic and custom plans in pg_stat_statements
Next
From: James Hunter
Date:
Subject: Re: Should work_mem be stable for a prepared statement?