On Tue, Oct 03, 2006 at 12:13:43 -0700, Graham Davis <gdavis@xxxxxxxxxxxxxxx> wrote: > Also, the multikey index of (assetid, ts) would already be sorted and > that is why using such an index in this case is > faster than doing a sequential scan that does the sorting afterwards. That isn't necessarily true. The sequentional scan and sort will need a lot fewer disk seeks and could run faster than using an index scan that has the disk drives doing seeks for every tuple (in the worst case, where the on disk order of tuples doesn't match the order in the index). If your server is caching most of the blocks than the index scan might give better results. You might try disabling sequentional scans to try to coerce the other plan and see what results you get. If it is substantially faster the other way, then you might want to look at lowering the random page cost factor. However, since this can affect other queries you need to be careful that you don't speed up one query at the expense of a lot of other queries.
