On Thu, Jan 21, 2010 at 1:28 PM, Leonardo F <m_lists@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