Hi!
On 16.03.2020 16:17, Alexander Korotkov wrote:
> After another try to polish this patch I figured out that the way it's
> implemented is unnatural. I see the two reasonable ways to implement
> knn for B-tree, but current implementation matches none of them.
>
> 1) Implement knn as two simultaneous scans over B-tree: forward and
> backward. It's similar to what current patchset does. But putting
> this logic to B-tree seems artificial. What B-tree does here is still
> unidirectional scan. On top of that we merge results of two
> unidirectional scans. The appropriate place to do this high-level
> work is IndexScan node or even Optimizer/Executor (Merge node over to
> IndexScan nodes), but not B-tree itself.
> 2) Implement arbitrary scans in B-tree using priority queue like GiST
> and SP-GiST do. That would lead to much better support for KNN. We
> can end up in supporting interesting cases like "ORDER BY col1 DESC,
> col2 <> val1, col2 ASC" or something. But that's requires way more
> hacking in B-tree core.
I've rebased and fixed the 17th version of this patch to work
with current master as a starting point for further development.
At first i'm going to implement p.1). I think it's preferable for now
because it seems easier and faster to get a working version.
If there are any ideas pro and contra would be glad to discuss them.
With the best wishes!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
