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 02:27:09 |
Message-ID: | 603c8f071002121827n232412acod8319337f647cea5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 12, 2010 at 9:10 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Feb 12, 2010 at 7:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe a more general idea would be to invent "categories" of opclass
>> members, where the only existing category is "index search qualifier",
>> and these new knngist thingies are another, and maybe plus and minus for
>> window function ranges are a third. But I'm not sure what you do if one
>> operator can be in more than one category.
>
> Well, if you were willing to change pg_amop so that the key was
> (amopfamily, amoplefttype, amoprighttype, amopcategory) rather than
> just (amopfamily, amoplefttype, amoprighttype), the issue of what to
> do if an operator can be in more than one category becomes moot. You
> just specify the operator more than once if need be.
Except I'm full of it, because amopstrategy is in there too. Hmm.
And that's unfortunate because the syscache machinery is limited to
four columns as lookup keys.
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".
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-02-13 02:31:56 | Re: Writeable CTEs and empty relations |
Previous Message | Robert Haas | 2010-02-13 02:14:47 | Re: Package namespace and Safe init cleanup for plperl [PATCH] |