Re: get_relation_stats_hook()
От | Tom Lane |
---|---|
Тема | Re: get_relation_stats_hook() |
Дата | |
Msg-id | 17759.1214499056@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: get_relation_stats_hook() (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: get_relation_stats_hook()
|
Список | pgsql-hackers |
Simon Riggs <simon@2ndquadrant.com> writes: >> Surely you didn't mean ALL calls. Please be more specific about what >> you're proposing. > The statistics relation STATRELATT is accessed in a few places in the > planner. Since it is in the syscache it is accessed directly from there. > I would like to add hooks so that stats data can come from somewhere > else other than the syscache for tables, just as we can already do with > get_relation_stats_hook(). Well, defining the hooks as replacing STATRELATT lookups seems the wrong level of abstraction. What if you want to insert stats that can't be represented by the current pg_statistic definition? Even if there's no functional limitation, cons'ing up a dummy pg_statistic tuple seems the hard way to do it --- we didn't define get_relation_info_hook as working by supplying made-up catalog rows. Furthermore, many of the interesting cases that someone might want to hook into are code paths that don't even try to look up a pg_statistic row because they know there won't be one, such as two out of the three cases in examine_variable(). I think you need to move up a level, and perhaps refactor some of the existing code to make it easier to inject made-up stats. regards, tom lane
В списке pgsql-hackers по дате отправления: