On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 12, 2010 at 9:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Robert Haas <robertmhaas@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 ...
Sigh.
...Robert
