X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id B6944528B1 for ; Sun, 29 May 2005 13:33: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 97075-06 for ; Sun, 29 May 2005 16:33:19 +0000 (GMT) Received: from flake.decibel.org (flake.decibel.org [67.100.216.10]) by svr1.postgresql.org (Postfix) with ESMTP id 17FA05284F for ; Sun, 29 May 2005 13:33:13 -0300 (ADT) Received: by flake.decibel.org (Postfix, from userid 1001) id 5A72115232; Sun, 29 May 2005 11:33:12 -0500 (CDT) Date: Sun, 29 May 2005 11:33:12 -0500 From: "Jim C. Nasby" To: Christopher Kings-Lynne Cc: mark durrant , pgsql-performance@postgresql.org Subject: Re: Select performance vs. mssql Message-ID: <20050529163312.GK44623@decibel.org> References: <20050524153637.64525.qmail@web53101.mail.yahoo.com> <4293D500.8010908@familyhealth.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4293D500.8010908@familyhealth.com.au> X-Operating-System: FreeBSD 4.11-RELEASE i386 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.8i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.005 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200505/422 X-Sequence-Number: 12586 On Wed, May 25, 2005 at 09:29:36AM +0800, Christopher Kings-Lynne wrote: > >--MSSQL's ability to hit the index only and not having > >to go to the table itself results in a _big_ > >performance/efficiency gain. If someone who's in > >development wants to pass this along, it would be a > >nice addition to PostgreSQL sometime in the future. > >I'd suspect that as well as making one query faster, > >it would make everything else faster/more scalable as > >the server load is so much less. > > This is well-known and many databases do it. However, due to MVCC > considerations in PostgreSQL, it's not feasible for us to implement it... Wasn't there a plan to store some visibility info in indexes? IIRC the idea was that a bit would be set in the index tuple indicating that all transactions that wouldn't be able to see that index value were complete, meaning that there was no reason to hit the heap for that tuple. I looked on the TODO but didn't see this, maybe it fell through the cracks? -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"