On Thu, Mar 2, 2017 at 5:57 PM, David Steele wrote:
> Hi Alexander,
>
> On 2/16/17 11:20 AM, Robert Haas wrote:
> > On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Thu, Feb 16, 2017 at 8:05 AM,
Hi Alexander,
On 2/16/17 11:20 AM, Robert Haas wrote:
> On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov
>>> wrote:
My idea is that we need
On Thu, Feb 16, 2017 at 10:59 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov
>> wrote:
>>> My idea is that we need more general redesign of specifying ordering which
>>> index
Robert Haas writes:
> On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov
> wrote:
>> My idea is that we need more general redesign of specifying ordering which
>> index can produce. Ideally, we should replace amcanorder, amcanbackward and
>>
On Thu, Feb 16, 2017 at 8:05 AM, Alexander Korotkov
wrote:
> My idea is that we need more general redesign of specifying ordering which
> index can produce. Ideally, we should replace amcanorder, amcanbackward and
> amcanorderbyop with single callback. Such callback
Hi, Nikita!
I have assigned as a reviewer for this patchset. I took a fist look to
these patches.
At first, I'd like to notice that it's very cool that you picked up this
work. I frequently hear people complains about lack of this feature.
k | kNN-btree | kNN-GiST| Opt. query
Sorry for the broken formatting in my previous message.
Below is a corrected version of this message.
I'd like to present a series of patches that implements k-Nearest Neighbors
(kNN) search for btree, which can be used to speed up ORDER BY distance
queries like this:
SELECT * FROM events ORDER