Re: Hook for Selectivity Estimation in Query Planning
От | Matthias van de Meent |
---|---|
Тема | Re: Hook for Selectivity Estimation in Query Planning |
Дата | |
Msg-id | CAEze2WgOMZTe3MUpzEXAyxEo_Oo1Ehoyh2tMjjAxcw64V-kgfw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hook for Selectivity Estimation in Query Planning (Aleksander Alekseev <aleksander@timescale.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: