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 <br...@momjian.us> 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
