Both keys are text fields. Does it make any difference if PlayerID were
integer?
BTW, I think the real performance problem is when we use SELECT ... ORDER
BY PlayerID DESC, AtDate DESC LIMIT 1 in a VIEW. Please see my subsequent
email http://archives.postgresql.org/pgsql-performance/2005-06/msg00110.php
on this show-stopper problem for which I still have no clue how to get
around. Suggestions are much appreciated.
Thanks and regards, KC.
At 21:34 05/06/08, George Essig wrote:
>On 6/2/05, K C Lau <KCLau@attglobal.net> wrote:
>...
> >
> > select DISTINCT ON (PlayerID) PlayerID,AtDate from Player where
> > PlayerID='22220' order by PlayerID desc, AtDate desc;
> > The Player table has primary key (PlayerID, AtDate) representing data over
> > time and the query gets the latest data for a player.
> >
> >
>...
> > esdt=> explain analyze select DISTINCT ON (PlayerID) PlayerID,AtDate from
> > Player
> > where PlayerID='22220' order by PlayerID desc, AtDate desc;
> > Unique (cost=0.00..2507.66 rows=1 width=23) (actual time=0.000..187.000
> > rows=1 loops=1)
> > -> Index Scan Backward using pk_player on player (cost=0.00..2505.55
> > rows=8
> > 43 width=23) (actual time=0.000..187.000 rows=1227 loops=1)
> > Index Cond: ((playerid)::text = '22220'::text)
> > Total runtime: 187.000 ms
> >
>
>Is PlayerID an integer datatype or a text datatype. It seems like
>PlayerID should be an integer data type, but postgres treats PlayerID
>as a text data type. This is because the value '22220' is quoted in
>your query. Also, the explain analyze output shows "Index Cond:
>((playerid)::text = '22220'::text".
>
>George Essig
>
>---------------------------(end of broadcast)---------------------------
>TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match