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

Re: get_relation_stats_hook()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
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 16:50:56
Message-ID: 17759.1214499056@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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().

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

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2008-06-26 16:54:44
Subject: Re: Planner creating ineffective plans on LEFT OUTERjoins
Previous:From: Hiroshi SaitoDate: 2008-06-26 16:42:29
Subject: Re: MSVC 2003 compile error with pg8.3.3

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-06-26 17:10:01
Subject: Re: Fix pg_ctl restart bug
Previous:From: Josh BerkusDate: 2008-06-26 16:29:44
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches

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