Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id DB4D6650F6F for ; Thu, 26 Jun 2008 12:59:45 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 54335-01-10 for ; Thu, 26 Jun 2008 12:59:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail136035.authsmtp.com (outmail136035.authsmtp.com [62.13.136.35]) by postgresql.org (Postfix) with ESMTP id 76344650F72 for ; Thu, 26 Jun 2008 12:58:23 -0300 (ADT) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt3.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m5QFwIHS053707; Thu, 26 Jun 2008 16:58:18 +0100 (BST) Received: from [192.168.0.3] (85-211-229-155.dyn.gotadsl.co.uk [85.211.229.155]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id m5QFwBnc017751; Thu, 26 Jun 2008 16:58:11 +0100 (BST) Subject: Re: get_relation_stats_hook() From: Simon Riggs To: Tom Lane , Alvaro Herrera Cc: pgsql-hackers In-Reply-To: <16415.1214493494@sss.pgh.pa.us> References: <1214490037.3845.136.camel@ebony.site> <16415.1214493494@sss.pgh.pa.us> Content-Type: text/plain Date: Thu, 26 Jun 2008 17:02:50 +0100 Message-Id: <1214496170.3845.196.camel@ebony.site> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Server-Quench: adc00a8f-4398-11dd-8155-001185d377ca X-AuthRoute: OCdxZQATClZOTQEd DAteCiNZVAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFagNbZ0xf HGQLW1xEUVt7XGt/ aggfZQBDYEtPQQdo WVZIR1dNFgBqBAMB SEMbM281BVsVeH93 YkNjEHJaWkI0JBIu Qk4FHTsbYWRpYH0e URQMagtVdQZXfh9E a1h6AHAKZjZWKBg1 TUcAHxkaHhhlExEd TQwRGkgfRU8XHzk6 cAseFCk0Kk0CQCZz bnQn X-Authentic-SMTP: 61633235383639.squirrel.dmpriest.net.uk:1078/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/986 X-Sequence-Number: 120099 On Thu, 2008-06-26 at 11:18 -0400, Tom Lane wrote: > Simon Riggs 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