From: | "Gregory S(dot) Williamson" <gsw(at)globexplorer(dot)com> |
---|---|
To: | <vivek(at)staff(dot)ownmail(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: select query not using index |
Date: | 2006-12-02 12:28:11 |
Message-ID: | 71E37EF6B7DCC1499CEA0316A256832802B3E988@loki.wc.globexplorer.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Vivek --
If you could let people know what version of postgres, and which OS, it might help.
A guess: the planner sees that there are very few rows and decides that a sequential scan is faster (this is because a sequential scan on a table with only a few rows is probably done in one operation; retrieving index values and the actual data rows involves more trips to disk, potentially. You could test this by turning off seq scan as a user option and re-running the query.
I note that it is casting "vivek" as text and the underlying column varchar; in earlier versions of postgres this might cause a mismatch and confuse the planner; try casting as "WHERE username = 'vivek'::varchar" and see if that is an improvement.
HTH,
Greg Williamson
DBA
GlobeXplorer LLC
-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org on behalf of vivek(at)staff(dot)ownmail(dot)com
Sent: Sat 12/2/2006 3:05 AM
To: pgsql-general(at)postgresql(dot)org
Cc:
Subject: [GENERAL] select query not using index
Dear Friends,
I have a table as
\d userpref;
Table "public.userpref"
Column | Type | Modifiers
-------------+------------------------+------------------------------------------------
username | character varying(101) | not null
email | character varying(255) | not null
context | character varying(32) | not null default 'from_box'::character varying
Indexes:
"userpref_user_idx" btree (username)
Foreign-key constraints:
"userpref_username_fkey" FOREIGN KEY (username, email) REFERENCES users(username, email)
The index was created before the table was populated. There are 3 rows in the table for 3 different users. Now when I do a
EXPLAIN SELECT * from userpref where username = 'vivek';
QUERY PLAN
-----------------------------------------------------------
Seq Scan on userpref (cost=0.00..1.26 rows=1 width=349)
Filter: ((username)::text = 'vivek'::text)
EXPLAIN ANALYZE SELECT * from userpref where username = 'vivek';
QUERY PLAN
----------------------------------------------------------------------------------------------------
Seq Scan on userpref (cost=0.00..1.04 rows=1 width=70) (actual time=0.060..0.071 rows=1 loops=1)
Filter: ((username)::text = 'vivek'::text)
Total runtime: 0.216 ms
(3 rows)
It shows seq scan . It is not using the index perhaps. But I fail to understand why does it not use the index created? I have tried vacuuming the database, reindexing the table, running analyze command.
Can anyone tell me what am I doing wrong?
With warm regards.
Vivek J. Joshi.
vivek(at)staff(dot)ownmail(dot)com
Trikon Electronics Pvt. Ltd.
All science is either physics or stamp collecting.
-- Ernest Rutherford
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
-------------------------------------------------------
Click link below if it is SPAM gsw(at)globexplorer(dot)com
"https://mailscanner.globexplorer.com/dspam/dspam.cgi?signatureID=457169e3251904846743324&user=gsw(at)globexplorer(dot)com&retrain=spam&template=history&history_page=1"
!DSPAM:457169e3251904846743324!
-------------------------------------------------------
From | Date | Subject | |
---|---|---|---|
Next Message | A. Kretschmer | 2006-12-02 12:32:20 | Re: select query not using index |
Previous Message | vivek | 2006-12-02 11:05:47 | select query not using index |