> However, this query performs a sequence scan on the table, ignoring the
> call_idx13 index (the only difference is the addition of the aspid field
> in the order by clause):
You do not have an index which matches the ORDER BY, so PostgreSQL
cannot simply scan the index for the data you want. Thus is needs to
find all matching rows, order them, etc.
> 23:59:59.999' order by aspid, openeddatetime desc, callstatus desc,
> calltype desc, callkey desc limit 26;
aspid ASC, openeddatetime DESC, callstatus DESC, calltype DESC
> call_idx13 btree (aspid, openeddatetime, callstatus, calltype,
> callkey),
This index is: aspid ASC, openeddatetime ASC, callstatus ASC, calltype
ASC, callkey ASC
A reverse scan, would of course be DESC, DESC, DESC, DESC, DESC --
neither of which matches your requested order by, thus cannot help the
reduce the lines looked at to 26.
This leaves your WHERE clause to restrict the dataset and it doesn't do
a very good job of it. There are more than 450000 rows matching the
where clause, which means the sequential scan was probably the right
choice (unless you have over 10 million entries in the table).
Since your WHERE clause contains a single aspid, an improvement to the
PostgreSQL optimizer may be to ignore that field in the ORDER BY as
order is no longer important since there is only one possible value. If
it did ignore aspid, it would use a plan similar to the first one you
provided.
You can accomplish the same thing by leaving out aspid ASC OR by setting
it to aspid DESC in the ORDER BY. Leaving it out entirely will be
slightly faster, but DESC will cause PostgreSQL to use index
"call_idx13".
