On Tue, Jan 3, 2012 at 6:24 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Another point that requires some thought is that switching SnapshotNow >>> to be MVCC-based will presumably result in a noticeable increase in each >>> backend's rate of wanting to acquire snapshots. Hence, more contention >>> in GetSnapshotData can be expected. A single-threaded test case doesn't >>> prove anything at all about what that might cost under load. > >> This is obviously true at some level, but I'm not sure that it really >> matters. It's not that difficult to construct a test case where we >> have lots of people concurrently reading a table, or reading many >> tables, or writing a table, or writing many tables, but what kind of >> realistic test case involves enough DDL for any of this to matter? > > Um ... you're supposing that only DDL uses SnapshotNow, which is wrong. > I refer you to the parser, the planner, execution functions for arrays, > records, enums, any sort of relcache reload, etc etc etc. Yes, some > of that is masked by backend-internal caching, some of the time, but > it's folly to just assume that there are no SnapshotNow scans during > normal queries. > > None of this is necessarily grounds to reject a patch along the proposed > lines. I'm just asking for some benchmarking effort to establish what > the costs might be, rather than naively hoping they are negligible.
All of which is reasonable doubt. So far, all I'm saying is that on a couple of heavy duty cases that I've run, I haven't noticed a problem. That is sufficient for me to push forwards with a patch that does very close to what we want, so we can judge acceptability with wider tests. I'm not saying it will be acceptable a priori, only that it is worth trying because the benefits are high. The number of call points are also high. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
