From: | Reiner Dassing <dassing(at)wettzell(dot)ifag(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-sql(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Index of a table is not used (in any case) |
Date: | 2001-10-25 12:52:48 |
Message-ID: | 3BD80B20.F0C687CD@wettzell.ifag.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-sql |
Hello Tom!
Tom Lane wrote:
>
> Reiner Dassing <dassing(at)wettzell(dot)ifag(dot)de> writes:
> > explain select * from wetter order by epoche desc;
> > NOTICE: QUERY PLAN:
>
> > Index Scan Backward using wetter_epoche_idx on wetter
> > (cost=0.00..3216018.59 rows=20340000 width=16)
>
> > explain select * from wetter where epoche between '1970-01-01' and
> > '1980-01-01' order by epoche asc;
> > NOTICE: QUERY PLAN:
>
> > Sort (cost=480705.74..480705.74 rows=203400 width=16)
> > -> Seq Scan on wetter (cost=0.00..454852.00 rows=203400 width=16)
>
> It's hard to believe that you've done a VACUUM ANALYZE on this table,
> since you are getting a selectivity estimate of exactly 0.01, which
> just happens to be the default selectivity estimate for range queries.
> How many rows are there really in this date range?
>
Well, I did not claim that i made a VACUUM ANALYZE, I just set up a new
table
for testing purposes doing just INSERTs.
After VACUUM ANALYSE the results look like:
explain select * from wetter where epoche between '1970-01-01' and
test_wetter-# '1980-01-01' order by epoche asc;
NOTICE: QUERY PLAN:
Index Scan using wetter_epoche_idx on wetter (cost=0.00..3313780.74
rows=20319660 width=16)
EXPLAIN
Now, the INDEX Scan is used and therefore, the query is very fast, as
expected.
For me, as a user not being involved in all the intrinsics of
PostgreSQL, the question was
"Why is this SELECT so slow?" (this question is asked a lot of times in
this Mail lists)
Now, I would like to say thank you! You have explained me and hopefully
many more users
what is going on behind the scene.
> Anyway, the reason the planner is picking a seqscan+sort is that it
> thinks that will be faster than an indexscan. It's not necessarily
> wrong. Have you compared the explain output and actual timings both
> ways? (Use "set enable_seqscan to off" to force it to pick an indexscan
> for testing purposes.)
>
> regards, tom lane
--
Mit freundlichen Gruessen / With best regards
Reiner Dassing
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-10-25 12:55:23 | Re: Kind of "bug-report" |
Previous Message | Tom Lane | 2001-10-25 12:49:43 | Re: timeout for "idle in transaction" |
From | Date | Subject | |
---|---|---|---|
Next Message | Max Buvry | 2001-10-25 14:55:33 | [Q] External join |
Previous Message | John Hasler | 2001-10-25 12:33:04 | Re: GUID in postgres |