On Mon, 7 Jul 2003, Dmitry Tkach wrote:
> I understand that with the generic approach to operators in postgres it
> is, probably, not very feasible to try and teach _bt_first () to handle
> this situation automatically (it would need to know how to get
> next/previous value for every indexable type)... I guess, that could be
> done by adding another kind of strategy to pg_amop for example...
> Another way to work around this would be to allow ordering spec to be a
> part of CREATE INDEX (I know, that informix does that for example) - so
> that, I could do
> create index huge_table_idx on huge_table (x, y desc);
> ... and then select * from huge_table where x=10 order x, y desc;
> would not require a backwards scan to begin with.
>
> Can something like this be done? What do you think?
If you make an opclass that orders in the reverse order you can use that
opclass in creating the index (which effectively can give you an index
like x, y desc by using the new opclass on y). There was some talk
recently about whether we should provide such opclasses as builtins or
contrib items.