From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Giorgio Valoti <giorgio_v(at)mac(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query Plan choice with timestamps |
Date: | 2008-08-07 15:50:59 |
Message-ID: | 12707.1218124259@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Giorgio Valoti <giorgio_v(at)mac(dot)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?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Giorgio Valoti | 2008-08-07 18:37:09 | Re: Query Plan choice with timestamps |
Previous Message | Joshua Shanks | 2008-08-07 15:11:43 | Re: query planner not using the correct index |