Earthman, that's already answered in the post:
INFO: "users": scanned 3000 of 32866 pages, containing 111000 live rows and 0 dead rows; 3000 rows in sample, 1216042 estimated total rows
no dead rows...stats are fresh.
Actually someone here found the answer:
Postgres' type hinting is the culprit. Passcode is a varchar(20) typed field. Preparing getUIDFromPasscode as given results in a prepared query that takes a char(20) which is then internally/implicitly converted back into an integer during the binding, and then converted back into a varchar(20) for actual lookup/comparison purposes.
As evidence supporting this, I offer the following, performed on asgqa3's database:
**** NOTE HERE the '' marks around $1 **** vappscb=# PREPARE getUIDFromPasscode(char(20
QUERY PLAN
--------------------------
Index Scan using uq_users_passcode on users (cost=0.00..3.01 rows=1 width=8)
Index Cond: ((passcode)::text = '$1'::text)
(2 rows)
vappscb=# explain SELECT userid FROM users WHERE passcode='20000112';
QUERY PLAN
--------------------------
Index Scan using uq_users_passcode on users (cost=0.00..3.01 rows=1 width=8)
Index Cond: ((passcode)::text = '20000112'::text)
(2 rows)
Main Topics
Browse All Topics





by: earthman2Posted on 2009-10-07 at 08:15:43ID: 25516427
vappscb=# vacuum full analyze;