Re: [HACKERS] 6.5 beta and ORDER BY patch

> Next thing to attack then would be aggregates, so that they too can
> benefit from indexes, I can immediately think of MIN, MAX and COUNT
> on simple scans. But as the aggregates are user-defined, we probably
> need a flag that tells the optimiser if said aggregate can in fact
> use indexes (and what type of index)
>
> Maybe we can even cache some data (for example tuple count) in
> backend, so that COUNT(*) can be made real fast ?
>
> After that the reverse index scans, so that the index that are
> backwards can also be used for sorting.
> BTW, can this be easily implemented/effective in PostgreSQL or are
> our btree indexes optimised for forward scans ?

Jan, I have kept the postings on optimizing LIMIT for joins. Let me
know if/when you want to see them.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026