Re: KNNGiST for knn-search (WIP)
| От | Teodor Sigaev |
|---|---|
| Тема | Re: KNNGiST for knn-search (WIP) |
| Дата | |
| Msg-id | 4B0FEF06.5050703@sigaev.ru обсуждение исходный текст |
| Ответ на | Re: KNNGiST for knn-search (WIP) (Teodor Sigaev <teodor@sigaev.ru>) |
| Ответы |
Re: KNNGiST for knn-search (WIP)
|
| Список | 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/
Вложения
В списке pgsql-hackers по дате отправления: