|From:||Simon Riggs <simon(at)2ndquadrant(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Thu, 2008-06-26 at 12:50 -0400, Tom Lane wrote:
> 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
> > 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
> 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
|Next Message||Josh Berkus||2008-06-26 19:03:43||Re: Latest on CITEXT 2.0|
|Previous Message||Simon Riggs||2008-06-26 18:16:03||Re: Planner creating ineffective plans on LEFT OUTER joins|
|Next Message||Bruce Momjian||2008-06-26 18:58:05||Re: Fix pg_ctl restart bug|
|Previous Message||Bruce Momjian||2008-06-26 17:10:01||Re: Fix pg_ctl restart bug|