Re: KNNGiST for knn-search (WIP)

>> Done, IndexScan and IndexPath have separate field to store order clauses.
> 
> Why?  Isn't that redundant with the pathkey structures?  We generate
> enough paths during a complex planning problem that I'm not in favor
> of adding unnecessary structures to them.
I found two ways to add support of knn-seaech to planner
- 0.4 version: add sorting clauses to restrictclauses in find_usable_indexes,  and there is two issues:  -
find_usable_indexescould not be used to find indexes for index and bitmap    scans at once, because sorting clauses
willbe used in bitmap scan. Full    scan of index with knn-ordering on large index is much more expensive.  -
implied/refusedpredicate machinery is teached to ignore sorting clauses,    but it's not so obvious: it should ignore
operationreturning non-boolean    values
 
- 0.4.1 version: pull sort clauses separately and merge them with regular  clauses at create_indexscan_plan function.
That'ssolves problems above
 

Do you suggest to construct that clauses from pathkey representation? And append  constructed clauses to indexquals in
create_indexscan_plan?
-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/