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