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>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: get_relation_stats_hook()
Date: 2008-06-26 16:02:50
Message-ID: 1214496170.3845.196.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Thu, 2008-06-26 at 11:18 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Currently we have a plugin capability for get_relation_info_hook(), but
> > no corresponding capability for statistics info.
> 
> > So, all calls to SearchSysCache would be replaced with a call to
> > get_relation_info_hook(), if present.
> 
> 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(). These new changes would complete the existing
feature to ensure it is fully usabled in the way originally intended.

In selfunc.c: There are 3 calls to SearchSysCache(STATRELATT,...).

In lsyscache.c: There is 1 call to SearchSysCache(STATRELATT...) in
get_attavgwidth() and 2 calls to SysCacheGetAttr(STATRELATT...) in
get_attstatsslot().

Calls to SearchSysCache(STATRELATT...) would be replaced by a call to an
external module, if present, with a function pointer to
get_relation_stats_hook(). This returns a tuple with stats info about
that relation.

Calls to SysCacheGetAttr(STATRELATT...) would be replaced by a call to
an external module, if present with a function pointer to
get_attribute_stats_hook(). This returns a stats slot.

The call in ANALYZE would not be touched.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

Responses

pgsql-hackers by date

Next:From: David E. WheelerDate: 2008-06-26 16:02:56
Subject: Re: Latest on CITEXT 2.0
Previous:From: Pavel StehuleDate: 2008-06-26 15:40:13
Subject: proposal: to_ascii(bytea)

pgsql-patches by date

Next:From: Josh BerkusDate: 2008-06-26 16:29:44
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches
Previous:From: KaiGai KoheiDate: 2008-06-26 15:32:32
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches

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