On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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 ...
Sigh. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers