Re: Why DISTINCT ... DESC is slow?

> > =# \d n_traffic
> >                         Table "public.n_traffic"
> >    Column    |            Type             |          Modifiers
> > --------------+-----------------------------+------------------------------
> > login_id     | integer                     | not null
> > traftype_id  | integer                     | not null
> > collect_time | timestamp without time zone | not null default now()
> > bytes_in     | bigint                      | not null default (0)::bigint
> > bytes_out    | bigint                      | not null default (0)::bigint
> > Indexes:
> >    "n_traffic_collect_time" btree (collect_time)
> >    "n_traffic_login_id" btree (login_id)
> >    "n_traffic_login_id_collect_time" btree (login_id, collect_time)
> > Foreign-key constraints:
> >    "n_traffic_login_id_fkey" FOREIGN KEY (login_id) REFERENCES
> > n_logins(login_id) ON UPDATE CASCADE
> >    "n_traffic_traftype_id_fkey" FOREIGN KEY (traftype_id) REFERENCES
> > n_traftypes(traftype_id) ON UPDATE CASCADE
>
> Why do you have indexes on both LOGIN_ID *and* LOGIN_ID + COLLECT_TIME?
It is because I think that queries which use only LOGIN_ID field will
use (faster) LOGIN_IDonly index... For me, speed of insertions is not
a primary task here (robot is not confused by delays...), but select
is. So I keep both indexes.

> ISTM that you can drop the LOGIN_ID index.
--
engineer