> 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@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
