Re: Why DISTINCT ... DESC is slow?

Поиск
Список
Период
Сортировка
От Anton
Тема Re: Why DISTINCT ... DESC is slow?
Дата
Msg-id 8cac8dd0612122113q761eddb0xdd66c128e85c666c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Why DISTINCT ... DESC is slow?  (Ron Johnson <ron.l.johnson@cox.net>)
Ответы Re: Why DISTINCT ... DESC is slow?  (Ron Johnson <ron.l.johnson@cox.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: resetting sequence to cur max value
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: TIMESTAMP WITHOUT TIME ZONE