Re: get_relation_stats_hook()

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>
Subject: Re: get_relation_stats_hook()
Date: 2008-06-26 18:29:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers pgsql-patches

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
PostgreSQL Training, Services and Support

In response to

Browse pgsql-hackers by date

  From Date Subject
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

Browse pgsql-patches by date

  From Date Subject
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