> Well, the expression cases would be more likely to cost more if > implemented as a sort, but that doesn't mean that a sort couldn't be a > win. Besides, even if you blow off the expression case, what about > nulls first/last, nondefault opclasses, etc?
Ok, let's split the problem in 2 parts: a) "choosing the right path" b) "using seq scan + sort in case the planner (somehow) said it's faster" You're right: for a) nondefault opclasses and other things would make the SPI version "wrong". So let's stick for the moment with the cost_sort create_index_path etc calls for a). I think that the calls to create_index_path would also deal with every other possible index type (something that's impossible with the SPI version). For b): I'm using the code in http://archives.postgresql.org/pgsql-hackers/2008-08/msg01371.php That doesn't deal with expression indexes, nor with anything that is not a btree index. But it's much faster on what people use the most (and not slower on anything else). So my proposal would be: do the test seq_scan vs sort/index_scan only for regular btree index, and integrate that test in the planner. That doesn't mean that sometime in the future we're not going to have full support for all index types in seq scan + sort CLUSTER... but I would like to have something that works faster on what people use, and not slower in the other cases without waiting ages to have the "whole" thing... -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
