On Wed, Mar 6, 2013 at 2:14 PM, Josh Berkus <j...@agliodbs.com> wrote: > Based on Smith's report, I consider (2) to be a deal-killer right now.
I was pretty depressed by those numbers, too. > The level of overhead reported by him would prevent the users I work > with from ever employing checksums on production systems. Agreed. > Specifically, the writing checksums for a read-only query is a defect I > think is prohibitively bad. That particular part doesn't bother me so much as some of the others - but let's step back and look at the larger issue. I suspect we can all agree that the performance of this feature is terrible. The questions I think we should be asking are: 1. Are the problems fundamental, or things where we can reasonable foresee future improvement? The latter situation wouldn't bother me very much even if the current situation is pretty bad, but if there's no real hope of improvement, that's more of a problem. 2. Are the performance results sufficiently bad that we think this would be more of a liability than an asset? > When we first talked about this feature for > 9.2, we were going to exclude hint bits from checksums, in order to > avoid this issue; what happened to that? I don't think anyone ever thought that was a particularly practical design. I certainly don't. > (FWIW, I still support the idea of moving hint bits to a separate > filehandle, as we do with the FSM, but clearly that's not happening for > 9.3 ...) Or, most likely, ever. The whole benefit of hint bits is that the information you need is available in the same bytes you have to read anyway. Moving the information to another fork (not filehandle) would probably give up most of the benefit. -- 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