Simon Riggs <simon(at)2ndquadrant(dot)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
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
In response to
pgsql-hackers by date
|Next:||From: Simon Riggs||Date: 2008-06-26 16:54:44|
|Subject: Re: Planner creating ineffective plans on LEFT OUTERjoins|
|Previous:||From: Hiroshi Saito||Date: 2008-06-26 16:42:29|
|Subject: Re: MSVC 2003 compile error with pg8.3.3|
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2008-06-26 17:10:01|
|Subject: Re: Fix pg_ctl restart bug|
|Previous:||From: Josh Berkus||Date: 2008-06-26 16:29:44|
|Subject: Re: [0/4] Proposal of SE-PostgreSQL patches|