On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F <m_li...@yahoo.it> wrote: >> 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...
Keep in mind that this patch was after the deadline for 9.0, so there is probably not a huge rush to get this done. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
