Re: Slow query performance on large table

Tomasz Myrta wrote:

> You are right - primary key should be ok, but Paul lost it. psql \d
> shows primary key indexes, but in this case there was no such primary
> key.
>
> Regards,
> Tomasz Myrta
>
Ok,

then my view of the world is all right again.

Re Tom Lane

> One would like to think the optimizer will make the right choice. But
> using a two-column index just because it's there isn't necessarily the
> right choice. The two-column index will certainly be bulkier and more
> expensive to scan, so if there's a one-column index that's nearly as
> selective, it might be a better choice.

If I know that the access pattern of my app looks as if it will need a
multipart index I should create it. If the optimizer finds out, a
simpler one will fit better, all right, it knows better (if properly
VACUUMed :-). But it's still good practice to offer complete indices.
Will pgsql use a multipart index as efficiently for simpler queries as a
shorter one covering only the first columns? In this example, the
(assessment, time) index could replace the (accessment) index, but
certainly not the (time) index. I tend to design longer indices with
hopefully valuable columns.

In this context:
From MSSQL, I know "covering indices". Imagine a table t with many
columns, and an index on (a,b,c).
in MSSQL, SELECT c from t where (a ... AND b...) will use that index to
retrieve the c column value also without touching the row data. In a
sense, the index is used as an alternative table. Does pgsql profit from
this kind of indices also?

Regards,

Andreas