Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFh4-0005oq-7m for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Feb 2014 15:56:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WDFh3-0007zR-OH for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Feb 2014 15:56:17 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFh1-0007xp-QG for pgsql-hackers@postgresql.org; Tue, 11 Feb 2014 15:56:15 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WDFgz-0007eb-24 for pgsql-hackers@postgresql.org; Tue, 11 Feb 2014 15:56:15 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1WDFgt-0001h1-TO; Tue, 11 Feb 2014 10:56:07 -0500 Date: Tue, 11 Feb 2014 10:56:07 -0500 From: Bruce Momjian To: Robert Haas Cc: Andres Freund , Jim Nasby , Alvaro Herrera , Peter Geoghegan , Tom Lane , Andrew Dunstan , PostgreSQL-development Subject: Re: [PERFORM] encouraging index-only scans Message-ID: <20140211155607.GB2289@momjian.us> References: <20130906170159.GB13158@momjian.us> <20130906191330.GA13193@momjian.us> <20130906222623.GC626072@alap2.anarazel.de> <20130907002908.GA12753@momjian.us> <20130907053449.GE626072@alap2.anarazel.de> <5238854F.5040708@nasby.net> <20130917231050.GD29545@awork2.anarazel.de> <20140201032207.GD31141@momjian.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Mon, Feb 3, 2014 at 11:55:34AM -0500, Robert Haas wrote: > > Robert, where are we on this? Should I post a patch? > > I started working on this at one point but didn't finish the > implementation, let alone the no-doubt-onerous performance testing > that will be needed to validate whatever we come up with. It would be > really easy to cause serious regressions with ill-considered changes > in this area, and I don't think many people here have the bandwidth > for a detailed study of all the different workloads that might be > affected here right this very minute. More generally, you're sending > all these pings three weeks after the deadline for CF4. I don't think > that's a good time to encourage people to *start* revising old > patches, or writing new ones. > > I've also had some further thoughts about the right way to drive > vacuum scheduling. I think what we need to do is tightly couple the I understand the problems with vacuum scheduling, but I was trying to address _just_ the insert-only workload problem for index-only scans. Right now, as I remember, only vacuum sets the visibility bits. If we don't want to make vacuum trigger for insert-only workloads, can we set pages all-visible more often? Is there a reason that a sequential scan, which does do page pruning, doesn't set the visibility bits too? Or does it? Can an non-index-only index scan that finds the heap tuple all-visible and the page not all-visible check the other items on the page to see if the page can be marked all-visible? Does analyze set pages all-visible? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers