Re: Fix for Index Advisor related hooks

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема Re: Fix for Index Advisor related hooks
Дата
Msg-id AANLkTinrpTy-=ZENFp1VitwkFvkfrJVFVyND0fp+L1YN@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Fix for Index Advisor related hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fix for Index Advisor related hooks  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: Debian readline/libedit breakage
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: arrays as pl/perl input arguments [PATCH]