Re: select max() much slower than select min()
От | Brian Cox |
---|---|
Тема | Re: select max() much slower than select min() |
Дата | |
Msg-id | 4A3ADE76.9030204@ca.com обсуждение исходный текст |
Ответ на | select max() much slower than select min() (Brian Cox <brian.cox@ca.com>) |
Ответы |
Re: select max() much slower than select min()
Re: select max() much slower than select min() |
Список | pgsql-performance |
Kevin Grittner [Kevin.Grittner@wicourts.gov] wrote: > Is there any correlation between ts_id and ts_interval_start_time? only vaguely: increasing ts_interval_start_time implies increasing ts_id but there may be many rows (100,000's) with the same ts_interval_start_time > Perhaps if you tried min and max with different time ranges it would > find a row on a backward scan faster. It'll take ten times as long if > it has to scan through ten times as many rows to find a match. it looks like there are fewer rows backwards than forwards: cemdb=> select count(*) from ts_stats_transet_user_interval where ts_interval_start_time < '2009-6-16 01:00'; count ---------- 32100000 (1 row) cemdb=> select count(*) from ts_stats_transet_user_interval where ts_interval_start_time >= '2009-6-16 02:00'; count ---------- 13500000 (1 row) > I don't suppose you have an index on ts_interval_start_time? there is an index. I mentioned this in my orginal posting. Thanks, Brian
В списке pgsql-performance по дате отправления: