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

Re: Fix for Index Advisor related hooks

From: Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix for Index Advisor related hooks
Date: 2011-02-16 18:30:35
Message-ID: AANLkTinrpTy-=ZENFp1VitwkFvkfrJVFVyND0fp+L1YN@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> writes:
> > I understand that we need to hide guts of an implementation. But without
> > this the Index Advisor will have to emulate what LookupOpclassInfo() does
> > and that's a lot of code that I am afraid, if emulated by another
> function
> > in Index Advisor, is more prone to obsolecence than calling
> > IndexSupportInitialize().
>
> The only reason you'd need that code is if you were trying to construct
> a fake Relation structure, which seems unnecessary and undesirable.
>

The planner requires IndexOptInfo, and for the planner to choose the
hypothetical index we need to fill in the fwdsortop, revsortop, opfamily and
opcintype, and this is the information that IndexAdvisor populates using
IndexSupportInitialize() (at least until c0b5fac7 changed the function
signature.

I am trying to populate an IndexOptInfo just like get_relation_info() does
after the 'info = makeNode(IndexOptInfo);' line.

What would be the best way to build an IndexOptInfo for a plain BTREE index
for different data types?

Regards,
-- 
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh(dot)gurjeet(at){ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-02-16 19:21:58
Subject: Re: arrays as pl/perl input arguments [PATCH]
Previous:From: Joshua D. DrakeDate: 2011-02-16 18:27:22
Subject: Re: Debian readline/libedit breakage

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