On Wed, Mar 6, 2013 at 2:14 PM, Josh Berkus <josh@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
