Skip site navigation (1) Skip section navigation (2)

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
Message-ID: 1214504993.3845.235.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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
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


In response to

pgsql-hackers by date

Next:From: Josh BerkusDate: 2008-06-26 19:03:43
Subject: Re: Latest on CITEXT 2.0
Previous:From: Simon RiggsDate: 2008-06-26 18:16:03
Subject: Re: Planner creating ineffective plans on LEFT OUTERjoins

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-06-26 18:58:05
Subject: Re: Fix pg_ctl restart bug
Previous:From: Bruce MomjianDate: 2008-06-26 17:10:01
Subject: Re: Fix pg_ctl restart bug

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group