Re: knngist patch support
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Oleg Bartunov <oleg@sai.msu.su>, tomas@tuxteam.de, Teodor Sigaev <teodor@sigaev.ru>, "Ragi Y. Burhum" <rburhum@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2010-02-13T03:39:17Z
Lists: pgsql-hackers
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