Re: select max() much slower than select min()

Поиск
Список
Период
Сортировка
От Brian Cox
Тема Re: select max() much slower than select min()
Дата
Msg-id 4A3BEF9A.4000201@ca.com
обсуждение исходный текст
Ответ на select max() much slower than select min()  (Brian Cox <brian.cox@ca.com>)
Ответы Re: select max() much slower than select min()  (David Rees <drees76@gmail.com>)
Список pgsql-performance
Tom Lane [tgl@sss.pgh.pa.us] wrote:
> Some experimentation suggests that it might help to provide a 2-column
> index on (ts_id, ts_interval_start_time).  This is still going to be
> scanned in order by ts_id, but it will be possible to check the
> ts_interval_start_time condition in the index, eliminating a large
> number of useless trips to the heap.  Whether this type of query is
> important enough to justify maintaining an extra index for is something
> you'll have to decide for yourself...

Thanks to all for the analysis and suggestions. Since the number of rows
in an hour < ~500,000, brute force looks to be a fast solution:

select ts_id from ... where ts_interval_start_time >= ... and ...

This query runs very fast as does a single pass through the ids to find
the min and max.

Brian

В списке pgsql-performance по дате отправления:

Предыдущее
От: Alan McKay
Дата:
Сообщение: Re: processor running queue - general rule of thumb?
Следующее
От: David Rees
Дата:
Сообщение: Re: select max() much slower than select min()