Re: KNNGiST for knn-search (WIP) - Mailing list pgsql-hackers

From Teodor Sigaev
Subject Re: KNNGiST for knn-search (WIP)
Date
Msg-id 4B0FEF06.5050703@sigaev.ru
Whole thread Raw
In response to Re: KNNGiST for knn-search (WIP)  (Teodor Sigaev <teodor@sigaev.ru>)
Responses Re: KNNGiST for knn-search (WIP)
List pgsql-hackers
> Planner (find_usable_indexes function, actually) could push pathkey
> expression into restriction clauses of index. I'm not fully satisfied
> with this piece of code, but, may be, someone has a better idea. I
> though about adding separate indexorderquals in IndexPath structure...

Done, IndexScan and IndexPath have separate field to store order clauses. That's
allowed to improve explain output:
#  EXPLAIN (COSTS OFF)
   SELECT * FROM point_tbl WHERE f1 <@ '(-10,-10),(10,10)':: box ORDER BY f1 <->
'0,1';
                    QUERY PLAN
------------------------------------------------
  Index Scan using gpointind on point_tbl
    Index Cond: (f1 <@ '(10,10),(-10,-10)'::box)
    Sort Cond: (f1 <-> '(0,1)'::point)
(3 rows)

We are waiting feedback to choose a way of planner support of knn-search.

Still TODO:
- cost of index scan
- Sort condition should not be ANDed in explain output
- current patch remove support of  IndexScanDesc->kill_prior_tuple, it's needed
to restore support if it will not create too big overhead
- documentation

--
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: unknown libpq service entries ignored
Next
From: Tom Lane
Date:
Subject: Re: KNNGiST for knn-search (WIP)