From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:39:17 |
Message-ID: | 603c8f071002121939y7315124cp2d2586f39ac15888@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 12, 2010 at 10:38 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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 ...
Sigh.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2010-02-13 04:08:38 | Re: Package namespace and Safe init cleanup for plperl [PATCH] |
Previous Message | Tom Lane | 2010-02-13 03:38:18 | Re: knngist patch support |