Hi! I've some questions regarding this patchset.
1) This comment needs to be revised. Now, B-tree supports both ammatchorderby and amcanbackward. How do we guarantee that kNN is not backwards scan? /* * Only forward scan is supported with reordering. Note: we can get away * with just Asserting here because the system will not try to run the * plan backwards if ExecSupportsBackwardScan() says it won't work. * Currently, that is guaranteed because no index AMs support both * ammatchorderby and amcanbackward; if any ever do, * ExecSupportsBackwardScan() will need to consider indexorderbys * explicitly. */ 2) Why this should be so? EXPLAIN (COSTS OFF) SELECT thousand, tenthous FROM tenk1 WHERE thousand IN (5, 120, 3456, 23) ORDER BY thousand DESC, tenthous <-> 3500; QUERY PLAN --------------------------------------------------------------------- Sort Sort Key: thousand DESC, ((tenthous <-> 3500)) -> Index Only Scan using tenk1_thous_tenthous on tenk1 Index Cond: (thousand = ANY ('{5,120,3456,23}'::integer[])) (4 rows) EXPLAIN (COSTS OFF) SELECT thousand, tenthous FROM tenk1 WHERE thousand IN (5, 120, 3456, 23) ORDER BY thousand, tenthous <-> 3500; QUERY PLAN --------------------------------------------------------------- Index Only Scan using tenk1_thous_tenthous on tenk1 Index Cond: (thousand = ANY ('{5,120,3456,23}'::integer[])) Order By: (thousand AND (tenthous <-> 3500)) (3 rows) It seems that we restart bidirectional scan for each value specified in IN clause. Then why does it matter whether it is forward or backward scan? 3) What is idea of 8th patch? It doesn't seem to be really needed for subsequent 9th patch, because we anyway ignore partial match pathkeys. Then why bother producing them? Is it stub for further incremental sort? ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company