Re: [HACKERS] Wrong index choosen?

[Dennis Bjorklund]

On Fri, 23 Jul 2004, Gaetano Mendola wrote:

 empdb=# explain analyze select * from v_past_connections where login_time  
 '2004-07-21';
QUERY PLAN
 --
   Index Scan 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=22477 loops=1)
 Index Cond: (login_time  '2004-07-21 00:00:00+02'::timestamp with time zone)
   Total runtime: 676.472 ms
 (3 rows)

In this plan it estimates to get 481 but it got 22477. So the estimation 
was very wrong. You can increase the statistics tarhet on the login_time 
and it will probably be better (after the next analyze).

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

Because it has to decide on the plan before it knows exactly what the 
result will be. As seen above, the estimation was wrong and thus the plan 
was not as good as it could have been.

In this case you probably also want to create a combined index on both
columns:

CREATE INDEX foo ON user_log (id_user, login_time);

ps. This letter belonged to pgsql-performance and not pgsql-hackers.

-- 
/Dennis Björklund


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly

Re: [HACKERS] Wrong index choosen?

[Tom Lane]

Dennis Bjorklund [EMAIL PROTECTED] writes:
 In this plan it estimates to get 481 but it got 22477. So the estimation 
 was very wrong. You can increase the statistics tarhet on the login_time 
 and it will probably be better (after the next analyze).

Given the nature of the data (login times), I'd imagine that the problem
is simply that he hasn't analyzed recently enough.  A bump in stats
target may not be needed, but he's going to have to re-analyze that
column often if he wants this sort of query to be estimated accurately,
because the fraction of entries later than a given time T is *always*
going to be changing.

regards, tom lane

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings