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()
|
Список | 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 по дате отправления: