pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
partial index regarded more expensive
4+ messages / 3 participants
[nested] [flat]

* partial index regarded more expensive
@ 2005-08-10 17:52  Tobias Brox <tobias@nordicbet.com>
  0 siblings, 2 replies; 4+ messages in thread

From: Tobias Brox @ 2005-08-10 17:52 UTC (permalink / raw)
  To: pgsql-performance

So, I have a table game with a timestamp attribute 'game_end', ranging from
jan-2005 to present.  The game table also have an attribute state, with live
games beeing in state 2, and ended games beeing in state 4 (so,
game_end+delta>now() usually means state=4).  There are also an insignificant
number of games in states 1,3.

This query puzzles me:

  select * from game where game_end>'2005-07-30' and state in (3,4);
  
Now, one (at least me) should believe that the best index would be a partial
index,

    "resolved_game_by_date" btree (game_end) WHERE ((state = 3) OR (state = 4))
    
NBET=> explain analyze select * from game where game_end>'2005-07-30' and state in (3,4);
                                                               QUERY PLAN   

----------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using resolved_game_by_date on game  (cost=0.00..7002.87 rows=7147 width=555) (actual time=0.220..86.234 rows=3852 loops=1)
   Index Cond: (game_end > '2005-07-30 00:00:00'::timestamp without time zone)
   Filter: ((state = 3) OR (state = 4))
 Total runtime: 90.568 ms
(4 rows)
      
Since state has only two significant states, I wouldn't believe this index
to be any good:

    "game_by_state" btree (state)
    

...and it seems like I'm right:

NBET=> explain analyze select * from game where game_end>'2005-07-30' and
state in (3,4);
                                                                   QUERY
PLAN                                                                   
------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using game_by_state, game_by_state on game  (cost=0.00..4413.78 rows=7147 width=555) (actual time=0.074..451.771 rows=3851 loops=1)
   Index Cond: ((state = 3) OR (state = 4))
      Filter: (game_end > '2005-07-30 00:00:00'::timestamp without time zone)
 Total runtime: 457.132 ms
(4 rows)

Now, how can the planner believe the game_by_state-index to be better?

('vacuum analyze game' did not significantly impact the numbers, and I've
tried running the queries some times with and without the
game_by_state-index to rule out cacheing effects)

-- 
Tobias Brox
This signature has been virus scanned, and is probably safe to read.
This mail may contain confidential information, please keep your eyes closed.



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: partial index regarded more expensive
@ 2005-08-10 18:15  PFC <lists@boutiquenumerique.com>
  parent: Tobias Brox <tobias@nordicbet.com>
  1 sibling, 1 reply; 4+ messages in thread

From: PFC @ 2005-08-10 18:15 UTC (permalink / raw)
  To: Tobias Brox <tobias@nordicbet.com>; pgsql-performance


	why not simply create an index on (game_end, state) ?



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: partial index regarded more expensive
@ 2005-08-10 18:31  Tobias Brox <tobias@nordicbet.com>
  parent: PFC <lists@boutiquenumerique.com>
  0 siblings, 0 replies; 4+ messages in thread

From: Tobias Brox @ 2005-08-10 18:31 UTC (permalink / raw)
  To: PFC <lists@boutiquenumerique.com>; +Cc: Tobias Brox <tobias@nordicbet.com>; pgsql-performance

[PFC - Wed at 08:15:13PM +0200]
> 	why not simply create an index on (game_end, state) ?

No, the planner prefers to use the partial index (I dropped the index on
game(state)).

-- 
Tobias Brox, Nordicbet IT dept
This signature has been virus scanned, and is probably safe to read.
This mail may contain confidential information, please keep your eyes closed.



^ permalink  raw  reply  [nested|flat] 4+ messages in thread

* Re: partial index regarded more expensive
@ 2005-08-11 03:14  Tom Lane <tgl@sss.pgh.pa.us>
  parent: Tobias Brox <tobias@nordicbet.com>
  1 sibling, 0 replies; 4+ messages in thread

From: Tom Lane @ 2005-08-11 03:14 UTC (permalink / raw)
  To: Tobias Brox <tobias@nordicbet.com>; +Cc: pgsql-performance

Tobias Brox <tobias@nordicbet.com> writes:
> This query puzzles me:
>   select * from game where game_end>'2005-07-30' and state in (3,4);
> ...
> Now, how can the planner believe the game_by_state-index to be better?

I suspect the problem has to do with lack of cross-column statistics.
The planner does not know that state=4 is correlated with game_end,
and it's probably coming up with some bogus guesses about the numbers
of index rows visited in each case.  You haven't given enough info to
quantify this, though.

			regards, tom lane



^ permalink  raw  reply  [nested|flat] 4+ messages in thread


end of thread, other threads:[~2005-08-11 03:14 UTC | newest]

Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2005-08-10 17:52 partial index regarded more expensive Tobias Brox <tobias@nordicbet.com>
2005-08-10 18:15 ` PFC <lists@boutiquenumerique.com>
2005-08-10 18:31   ` Tobias Brox <tobias@nordicbet.com>
2005-08-11 03:14 ` Tom Lane <tgl@sss.pgh.pa.us>

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox