X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 61A459FA226 for ; Tue, 9 May 2006 04:41:30 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 15478-07 for ; Tue, 9 May 2006 04:41:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from wolff.to (wolff.to [66.93.197.194]) by postgresql.org (Postfix) with SMTP id 4362A9F931D for ; Tue, 9 May 2006 04:41:23 -0300 (ADT) Received: (qmail 15423 invoked by uid 500); 9 May 2006 07:38:55 -0000 Date: Tue, 9 May 2006 02:38:55 -0500 From: Bruno Wolff III To: soni de Cc: Dave Dutcher , pgsql-performance@postgresql.org Subject: Re: Takes too long to fetch the data from database Message-ID: <20060509073855.GA11659@wolff.to> Mail-Followup-To: Bruno Wolff III , soni de , Dave Dutcher , pgsql-performance@postgresql.org References: <9f2e40a90604202142x5adbe6f0r7a993f8319619cc7@mail.gmail.com> <007801c66547$35e26270$8300a8c0@tridecap.com> <9f2e40a90605082054g6dd3e4f5ne3faf631e4792116@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f2e40a90605082054g6dd3e4f5ne3faf631e4792116@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/167 X-Sequence-Number: 18954 On Tue, May 09, 2006 at 09:24:15 +0530, soni de wrote: > > EXPLAIN > pdb=# EXPLAIN ANALYZE select * from wan where kname = 'pluto' order by stime > limit 50; > NOTICE: QUERY PLAN: > > Limit (cost=3515.32..3515.32 rows=50 width=95) (actual time= > 230492.69..230493.07 rows=50 loops=1) > -> Sort (cost=3515.32..3515.32 rows=208 width=95) (actual time= > 230492.68..230493.00 rows=51 loops=1) > -> Seq Scan on wan (cost=0.00..3507.32 rows=208 width=95) (actual > time=0.44..229217.38 rows=18306 loops=1) > Total runtime: 230631.62 msec Unless you have an index on (kname, stime) the query is going to need to find the records with a value for kname of 'pluto' and then get the most recent 50 of them. It looks like there are enough estimated records with kname = 'pluto', that a sequential scan is being prefered. Creating an extra index will slow down inserts somewhat, but will speed up queries like the above significantly, so may be worthwhile for you. I think later versions of Postgres are smarter, but for sure in 7.2 you will need to write the query like: SELECT * FROM wan WHERE kname = 'pluto' ORDER BY kname DESC, stime DESC LIMIT 50 ;