get_relation_stats_hook()
in [PgSql]
|
From: Simon Riggs on 26 Jun 2008 10:20 Currently we have a plugin capability for get_relation_info_hook(), but no corresponding capability for statistics info. So, all calls to SearchSysCache would be replaced with a call to get_relation_info_hook(), if present. Any objections, thoughts? -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 26 Jun 2008 11:14 Simon Riggs wrote: > Currently we have a plugin capability for get_relation_info_hook(), but > no corresponding capability for statistics info. > > So, all calls to SearchSysCache would be replaced with a call to > get_relation_info_hook(), if present. I assume you meant get_relation_stats_hook in the last paragraph, but I can't understand what you mean with SearchSysCache (surely that's not it.) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 Jun 2008 11:18 Simon Riggs <simon(a)2ndquadrant.com> writes: > Currently we have a plugin capability for get_relation_info_hook(), but > no corresponding capability for statistics info. > So, all calls to SearchSysCache would be replaced with a call to > get_relation_info_hook(), if present. Surely you didn't mean ALL calls. Please be more specific about what you're proposing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 26 Jun 2008 12:02 On Thu, 2008-06-26 at 11:18 -0400, Tom Lane wrote: > Simon Riggs <simon(a)2ndquadrant.com> writes: > > Currently we have a plugin capability for get_relation_info_hook(), but > > no corresponding capability for statistics info. > > > So, all calls to SearchSysCache would be replaced with a call to > > get_relation_info_hook(), if present. > > 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(). These new changes would complete the existing feature to ensure it is fully usabled in the way originally intended. In selfunc.c: There are 3 calls to SearchSysCache(STATRELATT,...). In lsyscache.c: There is 1 call to SearchSysCache(STATRELATT...) in get_attavgwidth() and 2 calls to SysCacheGetAttr(STATRELATT...) in get_attstatsslot(). Calls to SearchSysCache(STATRELATT...) would be replaced by a call to an external module, if present, with a function pointer to get_relation_stats_hook(). This returns a tuple with stats info about that relation. Calls to SysCacheGetAttr(STATRELATT...) would be replaced by a call to an external module, if present with a function pointer to get_attribute_stats_hook(). This returns a stats slot. The call in ANALYZE would not be touched. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 Jun 2008 12:50
Simon Riggs <simon(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |