On Fri, Jan 6, 2012 at 5:17 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> Its funny. I have the feeling we all are missing a very obvious brilliant >> solution to this... > > Like getting rid of hint bits?
No. First, that solution has been proposed before, and it crashed and burned before. You may as well propose getting rid of VACUUM. In each case, the supposed problem is in fact a cure for a much more severe problem that would quickly make you long for the days when you had the first one. I think you (or someone else?) had a fairly well-developed patch for blunting the impact of hint bit setting, and that we might be able to do if you (or someone) wants to finish it. But getting rid of them altogether isn't likely, not because PostgreSQL developers are an intractable herd of mule-headed idiots (although I have been known to be all of those things on occasion) but because the performance characteristics demonstrably suck, as mostly recently demonstrated by commit 4de82f7d7c50a81ec8e70e2cb0ab413ab9134c0b, which significantly improved performance with synchronous_commit=off by shaving about an average of one-tenth of one second off the time before hint bits could be set on any given tuple. Second, even if you did it, it wouldn't fix this problem, because hint bits aren't the only changes we make without WAL logging. In particular, when an index scan runs across a tuple that turns out to be dead, we kill the index tuple so that future scans don't need to revisit it. I haven't actually done any testing to measure how significant this is, but I wouldn't bet on it not mattering. I think it would be wonderful to come up with a design that either blunted the effect of hint bits or eliminated them altogether, but the idea that there's an obvious way forward there that we've simply refused to pursue is, AFAICT, flat wrong. Let's not get sidetracked into talking about things that aren't going to change in time for 9.2 (and probably not 9.3, either, given that no one seems to be putting any time into it) and aren't even feasible solutions to the problem at hand (checksums) anyway. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers