On Mon, Nov 22, 2010 at 11:05 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Nov 22, 2010 at 8:32 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
