Re: knngist patch support
От | Robert Haas |
---|---|
Тема | Re: knngist patch support |
Дата | |
Msg-id | 603c8f071002121939y7315124cp2d2586f39ac15888@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: knngist patch support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: knngist patch support
|
Список | 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
В списке pgsql-hackers по дате отправления: