Wrong index choosen? - Mailing list pgsql-hackers

From Gaetano Mendola
Subject Wrong index choosen?
Date
Msg-id 4100CBCC.5050308@bigfoot.com
Whole thread Raw
Responses Re: Wrong index choosen?  (Dennis Bjorklund <db@zigo.dhs.org>)
List pgsql-hackers
I hall
I have a query in this form:

empdb=# explain analyze select * from v_past_connections where id_user = 26195 and login_time > '2004-07-21';
                                                   QUERY PLAN
 

-----------------------------------------------------------------------------------------------------------------------------------------
IndexScan using idx_user_logs_login_time on user_logs  (cost=0.00..14.10 rows=1 width=28) (actual time=66.890..198.998
rows=5loops=1)   Index Cond: (login_time > '2004-07-21 00:00:00+02'::timestamp with time zone)   Filter: (id_user =
26195)Total runtime: 199.083 ms
 
(4 rows)


as you see the index on the time stamp column is used

The table have indexes on both columns:

empdb=# explain analyze select * from v_past_connections where login_time > '2004-07-21';
                                  QUERY PLAN
 

----------------------------------------------------------------------------------------------------------------------------------------------
IndexScan using idx_user_logs_login_time on user_logs  (cost=0.00..12.90 rows=481 width=28) (actual time=7.338..661.300
rows=22477loops=1)   Index Cond: (login_time > '2004-07-21 00:00:00+02'::timestamp with time zone) Total runtime:
676.472ms
 
(3 rows)

empdb=# explain analyze select * from v_past_connections where id_user = 26195;
                    QUERY PLAN
 

---------------------------------------------------------------------------------------------------------------------------------------
IndexScan using idx_user_user_logs on user_logs  (cost=0.00..252.47 rows=320 width=28) (actual time=4.420..100.122
rows=221loops=1)   Index Cond: (id_user = 26195) Total runtime: 100.348 ms
 
(3 rows)


The rows filtered out with both condictions are two order of magnitude differents,
also the extimated rows are close to real numbers:


empdb=# select count(*) from v_past_connections where id_user = 26195; count
-------   221
(1 row)

empdb=# select count(*) from v_past_connections where login_time > '2004-07-21'; count
------- 22441
(1 row)


why then the planner choose to do an index scan using the filter that retrieve a bigger ammount of rows ? A bug ?





Regards
Gaetano Mendola

















pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Fixing PKs and Uniques in tablespaces
Next
From: "Zeugswetter Andreas SB SD"
Date:
Subject: Re: Fixing PKs and Uniques in tablespaces