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 по дате отправления: