Robert Haas <robertmh...@gmail.com> writes:
> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmh...@gmail.com> writes:
>>> 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.
I think that's soluble though. The reason that index exists is to
enforce the rule that an operator can stand in only one relationship
to an opfamily. In this design the natural rule would be "one
relationship per role", ie, the unique key would become
(operator, category, opfamily).
However, that does make it even uglier to have category shoehorned in as
part of a different field. Back to wanting 5-key syscaches ...
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
