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_indexes could not be used to find indexes for index and bitmap
scans at once, because sorting clauses will be used in bitmap scan. Full
scan of index with knn-ordering on large index is much more expensive.
- implied/refused predicate machinery is teached to ignore sorting clauses,
but it's not so obvious: it should ignore operation returning non-boolean
values
- 0.4.1 version: pull sort clauses separately and merge them with regular
clauses at create_indexscan_plan function. That's solves 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: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
