From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Együd Csaba <csegyud(at)vnet(dot)hu> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Strange Index behavior |
Date: | 2004-12-22 16:46:54 |
Message-ID: | 4674.1103734014@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
=?iso-8859-2?Q?Egy=FCd_Csaba?= <csegyud(at)vnet(dot)hu> writes:
> # explain analyze select meterid, tstamp, pp, pm, status from measured_1
> where tstamp >= '2004.12.22 00:00' and tstamp <= '2004.12.22 23:59' order by
> tstamp, meterid;
> "Sort (cost=2619.02..2622.78 rows=1505 width=42) (actual
> time=1672.000..1682.000 rows=14523 loops=1)"
> " Sort Key: tstamp, meterid"
> " -> Seq Scan on measured_1 (cost=0.00..2539.59 rows=1505 width=42)
> (actual time=0.000..1292.000 rows=14523 loops=1)"
> " Filter: ((tstamp >= '2004-12-22 00:00:00'::timestamp without time
> zone) AND (tstamp <= '2004-12-22 23:59:00'::timestamp without time zone))"
> "Total runtime: 1802.000 ms"
Why do you say there are no such rows, when the explain output clearly
shows there are 14523 of them? The plan shift looks fairly reasonable
to me given the large number of rows to be retrieved.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-12-22 16:50:01 | Re: AREs in substring(from) |
Previous Message | Tom Lane | 2004-12-22 16:41:39 | Re: default index created for primary key |