Re: knngist patch support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, tomas(at)tuxteam(dot)de, Teodor Sigaev <teodor(at)sigaev(dot)ru>, "Ragi Y(dot) Burhum" <rburhum(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: knngist patch support
Date: 2010-02-13 03:38:18
Message-ID: 22821.1266032298@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-02-13 03:39:17 Re: knngist patch support
Previous Message Robert Haas 2010-02-13 03:18:38 Re: knngist patch support