From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: knngist - 0.8 |
Date: | 2010-11-23 16:04:18 |
Message-ID: | AANLkTim64XLz7MgkV8xKhTKmwd8RmYacGAv94ancgRQ0@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> On balance I'm inclined to leave the unique key as per previous proposal
>>> (with a "purpose" column) and add the which-sort-order-is-that
>>> information as payload columns that aren't part of the key.
>
>> This is probably OK too, although I confess I'm a lot less happy about
>> it now that you've pointed out the need for those payload columns.
>
> The reason I said "columns" is that I can foresee eventually wanting to
> specify a pathkey in its entirety --- opfamily, asc/desc, nulls_first,
> and whatever we come up with for collation. We don't currently need to
> store more than the opfamily, since the others can never need to have
> non-default values given the current implementation of KNNGIST. But the
> idea that they might all be there eventually makes me feel that we don't
> want to try to incorporate this data in pg_amop's unique key. I'm
> satisfied to say that only one sort order can be associated with a
> particular operator in a particular opclass, which is what would be
> implied by using AMOP_SEARCH/AMOP_ORDER as the unique key component.
Does that imply that KNNGIST would only be able to support one
ordering per AMOP_ORDER-operator, or does it imply that each such
ordering would require a separate strategy number? The second might
be OK, but the first sounds bad.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-23 16:12:29 | Re: knngist - 0.8 |
Previous Message | Robert Haas | 2010-11-23 15:54:25 | Re: [JDBC] Support for JDBC setQueryTimeout, et al. |