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 6321BD6FF5 for ; Wed, 24 Aug 2005 18:22:41 -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 75415-02 for ; Wed, 24 Aug 2005 21:22:34 +0000 (GMT) Received: from flake.decibel.org (flake.decibel.org [67.100.216.10]) by svr1.postgresql.org (Postfix) with ESMTP id 9A75CD7A64 for ; Wed, 24 Aug 2005 18:22:32 -0300 (ADT) Received: by flake.decibel.org (Postfix, from userid 1001) id DD02A1527C; Wed, 24 Aug 2005 16:22:34 -0500 (CDT) Date: Wed, 24 Aug 2005 16:22:34 -0500 From: "Jim C. Nasby" To: Mark Fox Cc: pgsql-performance@postgresql.org Subject: Re: Performance indexing of a simple query Message-ID: <20050824212234.GZ96732@pervasive.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 4.11-RELEASE-p10 i386 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.009 required=5 tests=[AWL=0.009] X-Spam-Level: X-Archive-Number: 200508/406 X-Sequence-Number: 14153 Try CREATE INDEX start_complete ON jobs( start_time, completion_time ); Try also completion_time, start_time. One might work better than the other. Or, depending on your data, you might want to keep both. In 8.1 you'll be able to do bitmap-based index combination, which might allow making use of the seperate indexes. On Wed, Aug 24, 2005 at 02:43:51PM -0600, Mark Fox wrote: > I have a table called 'jobs' with several million rows, and the only > columns that are important to this discussion are 'start_time' and > 'completion_time'. > > The sort of queries I want to execute (among others) are like: > > SELECT * FROM jobs > WHERE completion_time > SOMEDATE AND start_time < SOMEDATE; > > In plain english: All the jobs that were running at SOMEDATE. The > result of the query is on the order of 500 rows. > > I've got seperate indexes on 'start_time' and 'completion_time'. > > Now, if SOMEDATE is such that the number of rows with completion_time > > SOMEDATE is small (say 10s of thousands), the query uses index scans > and executes quickly. If not, the query uses sequential scans and is > unacceptably slow (a couple of minutes). I've used EXPLAIN and > EXPLAIN ANALYZE to confirm this. This makes perfect sense to me. > > I've played with some of the memory settings for PostgreSQL, but none > has had a significant impact. > > Any ideas on how to structure the query or add/change indexes in such > a way to improve its performance? In desperation, I tried using a > subquery, but unsurprisingly it made no (positive) difference. I feel > like there might be a way of using an index on both 'completion_time' > and 'start_time', but can't put a temporal lobe on the details. > > > Mark > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com 512-569-9461