| From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> | 
|---|---|
| To: | nick(at)club(dot)pyat(dot)ru, pgsql-bugs(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: SELECT min(id) FROM test; uses seqscan | 
| Date: | 2001-05-03 02:50:05 | 
| Message-ID: | 3.0.5.32.20010503125005.02dad200@mail.rhyme.com.au | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
At 09:08 2/05/01 -0400, pgsql-bugs(at)postgresql(dot)org wrote:
>SELECT min(id) FROM test; uses sequential scan even if an index on "id"
exists. VACUUM ANALYZE doesn't help.
>
This is a known stupidity of PG, and will probably be fixed in a relatively
distant future release (when index entries are updated to match row
status). The simple workaround is:
Select id from test order by id as limit 1;
----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2001-05-03 04:04:52 | Re: SELECT min(id) FROM test; uses seqscan | 
| Previous Message | pgsql-bugs | 2001-05-02 13:08:55 | SELECT min(id) FROM test; uses seqscan |