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().
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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
