Re: Why DISTINCT ... DESC is slow? - Mailing list pgsql-general

From Anton
Subject Re: Why DISTINCT ... DESC is slow?
Date
Msg-id 8cac8dd0612122113q761eddb0xdd66c128e85c666c@mail.gmail.com
Whole thread Raw
In response to Re: Why DISTINCT ... DESC is slow?  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Why DISTINCT ... DESC is slow?  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-general
> > =# \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

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: resetting sequence to cur max value
Next
From: Richard Huxton
Date:
Subject: Re: TIMESTAMP WITHOUT TIME ZONE