Re: Fix for Index Advisor related hooks - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: Fix for Index Advisor related hooks
Date
Msg-id AANLkTinrpTy-=ZENFp1VitwkFvkfrJVFVyND0fp+L1YN@mail.gmail.com
Whole thread Raw
In response to Re: Fix for Index Advisor related hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fix for Index Advisor related hooks
List pgsql-hackers
On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gurjeet Singh <singh.gurjeet@gmail.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.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Debian readline/libedit breakage
Next
From: Alvaro Herrera
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]