| From: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
|---|---|
| To: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add missing operator <->(box, point) |
| Date: | 2019-07-02 18:55:40 |
| Message-ID: | CAPpHfdtq4+AhjBhjEMkeLqi46pz-dEUs3=SQG-_nSPsw+hHAyA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 2, 2019 at 9:19 PM Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru> wrote:
> We could use commuted "const <-> var" operators for kNN searches, but the
> current implementation requires the existence of "var <-> const" operators, and
> order-by-op clauses are rebuilt using them (see match_clause_to_ordering_op()
> at /src/backend/optimizer/path/indxpath.c).
But probably it's still worth to just add commutator for every <->
operator and close this question. Otherwise, it may arise again once
we want to add some more kNN support to opclasses or something. On
the other hand, are we already going to limit oid consumption?
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-07-02 19:10:37 | Re: [PATCH v5] Show detailed table persistence in \dt+ |
| Previous Message | Nikita Glukhov | 2019-07-02 18:17:52 | Re: Add missing operator <->(box, point) |