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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: unknown libpq service entries ignored
Следующее
От: Tom Lane
Дата:
Сообщение: Re: KNNGiST for knn-search (WIP)