X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 23F9ED7E31 for ; Wed, 12 Oct 2005 10:00:21 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 90720-05 for ; Wed, 12 Oct 2005 13:00:14 +0000 (GMT) Received: from imsm057dat.netvigator.com (imsm057.netvigator.com [218.102.48.210]) by svr1.postgresql.org (Postfix) with ESMTP id 2C70AD7E11 for ; Wed, 12 Oct 2005 10:00:15 -0300 (ADT) Received: from n2.netvigator.com ([218.102.147.167]) by imsm057dat.netvigator.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051012130018.GZT14795.imsm057dat.netvigator.com@n2.netvigator.com>; Wed, 12 Oct 2005 21:00:18 +0800 Message-Id: <6.2.1.2.0.20051012203443.0512a588@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 12 Oct 2005 21:00:15 +0800 To: "Merlin Moncure" , pgsql-performance@postgresql.org From: K C Lau Subject: Re: SELECT LIMIT 1 VIEW Performance Issue In-Reply-To: <6EE64EF3AB31D5448D0007DD34EEB3417DD58A@Herge.rcsinc.local> References: <6EE64EF3AB31D5448D0007DD34EEB3417DD58A@Herge.rcsinc.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.536 required=5 tests=[AWL=-0.356, DNS_FROM_RFC_POST=1.376, FROM_ENDS_IN_NUMS=0.516] X-Spam-Level: * X-Archive-Number: 200510/206 X-Sequence-Number: 14974 Dear Merlin and all, That direct SQL returns in 0 ms. The problem only appears when a view is used. What we've done to work around this problem is to modify the table to add a field DataStatus which is set to 1 for the latest record for each player, and reset to 0 when it is superceded. A partial index is then created as: CREATE INDEX IDX_CurPlayer on Player (PlayerID) where DataStatus = 1; The VCurPlayer view is changed to: CREATE or REPLACE VIEW VCurPlayer as select * from Player where DataStatus = 1; and it now returns in 0 ms. This is not the best solution, but until (if ever) the original problem is fixed, we have not found an alternative work around. The good news is that even with the additional overhead of maintaining an extra index and the problem of vacuuming, pg 8.0.3 still performs significantly faster on Windows than MS Sql 2000 in our OLTP application testing so far. Thanks to all for your help. Best regards, KC. At 20:14 05/10/12, you wrote: >KC wrote: > > > > So I guess it all comes back to the basic question: > > > > For the query select distinct on (PlayerID) * from Player a where > > PlayerID='22220' order by PlayerId Desc, AtDate Desc; > > can the optimizer recognise the fact the query is selecting by the >primary > > key (PlayerID,AtDate), so it can skip the remaining rows for that > > PlayerID, > > as if LIMIT 1 is implied? > > > > Best regards, KC. > >Hi KC, have you tried: >select * from player where playerid = '22220' and atdate < 9999999999 >order by platerid desc, atdate desc limit 1; > >?? >Merlin