Re: Query Plan choice with timestamps
От | Giorgio Valoti |
---|---|
Тема | Re: Query Plan choice with timestamps |
Дата | |
Msg-id | A7C0E4E0-460D-49AB-912B-050E8049B16D@mac.com обсуждение исходный текст |
Ответ на | Re: Query Plan choice with timestamps (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Query Plan choice with timestamps
Re: Query Plan choice with timestamps |
Список | pgsql-performance |
On 07/ago/08, at 17:50, Tom Lane wrote: > Giorgio Valoti <giorgio_v@mac.com> writes: >> GroupAggregate (cost=98431.58..119773.92 rows=74226 width=8) >> -> Sort (cost=98431.58..99050.92 rows=247736 width=8) >> Sort Key: (day_trunc(ts)) >> -> Seq Scan on blackbox (cost=0.00..72848.36 rows=247736 >> width=8) > >> GroupAggregate (cost=0.00..19109.66 rows=74226 width=8) >> -> Index Scan using test_2_idx on blackbox >> (cost=0.00..16943.16 rows=247736 width=8) > > These numbers seem pretty bogus: there is hardly any scenario in > which a > full-table indexscan should be costed as significantly cheaper than a > seqscan. Have you put in silly values for random_page_cost? No, > > > If you haven't mucked with the cost parameters, the only way I can > think > of to get this result is to have an enormously bloated table that's > mostly empty. Maybe you need to review your vacuuming procedures. I’ll review them. Thank you -- Giorgio Valoti
В списке pgsql-performance по дате отправления: