On Thu, 2008-06-26 at 12:50 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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().
The reason for doing it this way is I'm interested in using stats literally copied from other servers. So the pg_statistic tuples will be available for us directly. I'm building a tool to allow people to export their production environment to a test system, so that SQL developers can experiment with query tuning and optimizer developers can recreate problems. > 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. Both sound like good ideas. I wasn't really after ultimate flexibility, but perhaps I should be. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers