Gurjeet Singh <singh.gurjeet@gmail.com> writes:
> On Wed, Feb 16, 2011 at 10:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
Yeah, and the set of stuff you need in IndexOptInfo changed again last
week; see collations. Direct access to IndexSupportInitialize is even
less useful today than it was a week ago. This stuff has changed many
times before, and it will change again in the future, and exporting a
private function that has an unrelated purpose is not going to insulate
you from needing to deal with that.
> What would be the best way to build an IndexOptInfo for a plain BTREE index
> for different data types?
Fetch the values you need and stuff 'em in the struct. Don't expect
relcache to do it for you. The only reason relcache is involved in the
current workflow is that we try to cache the information across queries
in order to save on planner startup time ... but I don't think that that
concern is nearly as pressing for something like Index Advisor. You'll
have enough to do tracking changes in IndexOptInfo, you don't need to
have to deal with refactorings inside relcache as well.
regards, tom lane
