On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane <tgl@sss.pgh.pa.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