Robert Haas <robertmh...@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...
> 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.
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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
