On Sun, May 15, 2016 at 4:06 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Overall, I think this shows that there seems to be no performance penalty > with "disabled" vs. "reverted" - i.e. even with the least favorable (100% > read-only) workload.
OK, that's good, as far as it goes. > Whatever the metric is, I think it's fairly clear the patch makes the > results way more volatile - particularly with the "immediate" case and > higher client counts. I think you mean only when it is enabled. Right? Mithun and others at EnterpriseDB have been struggling with the problem of getting reproducible results on benchmarks, even read-only benchmarks that seem like they ought to be fairly stable, and they've been complaining to me about that problem - not specifically with respect to snapshot too old, but in general. I don't have a clear understanding at this point of why a particular piece of code might cause increased volatility, but I wish I did. In the past, I haven't paid much attention to this, but lately it's clear that it is becoming a significant problem when trying to benchmark, especially on many-socket machines. I suspect it might be a problem for actual users as well, but I know of any definite evidence that this is the case. It's probably an area that needs a bunch of work, but I don't understand the problem well enough to know what we should be doing. > What I plan to do next, over the next week: > > 1) Wait for the second run of "immediate" to complete (should happen in a > few hours) > > 2) Do tests with other workloads (mostly read-only, read-write). Sounds good. -- 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
