Re: knngist patch support - Mailing list pgsql-hackers

On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>>> Well, if you were willing to change pg_amop so that the key was
>>> (amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
>>> just (amopfamily, amoplefttype, amoprighttype), the issue of what to
>>> do if an operator can be in more than one category becomes moot.  You
>>> just specify the operator more than once if need be.
>
> Yeah, that occurred to me too after sending my earlier email.
>
>> Except I'm full of it, because amopstrategy is in there too.  Hmm.
>> And that's unfortunate because the syscache machinery is limited to
>> four columns as lookup keys.
>
> Ugh.  Still, we could certainly change the 4-key limit to 5, though it
> might be a tad tedious to go round and edit all the SearchSysCache and
> related calls.  Maybe while we were at it we should change them to
> SearchSysCache1, SearchSysCache2, etc to not have the limit hardwired
> textually in quite so many places...

Maybe.  It sounds sort of awful though; and there's probably a
distributed performance penalty involved

>> This is a bit ugly, but one idea that occurs to me is to change
>> amopstrategy from int16 to int32.  Internally, we'll treat the low 16
>> bits as the strategy number and the high 16 bits as the strategy
>> category, with strategy category 0 being "index search qualifier".
>
> Hm, yeah that would work, but I agree it's ugly.

On further review there's a serious problem with this idea:
pg_amop_opr_fam_index.

> While thinking about different possible solutions here: one of the
> things that was worrying me is that for cases where the same operator
> can serve in more than one role, it might have to have either the same
> opstrategy or different ones in different roles, depending on how the AM
> has assigned strategy numbers.  The method with an extra index column
> side-steps that nicely since there are two unrelated pg_amop entries.
> If there's only one entry then you lose if you need different
> strategies.  Robert's use-the-high-bits method works too, since there
> would still be two separate entries, but some other possible
> representations are eliminated by that worry.

OK, here's another idea.  Let's just add a new column to pg_amop
called amoporderstrategy.  If an operator can only be used for one
purpose or the other, we'll set the other value to -1.

...Robert