Re: ALTER TABLE lock strength reduction patch is unsafe

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> That was acceptable to *me*, so I didn't try measuring using just SnapshotNow.

> We can do a lot of tests but at the end its a human judgement. Is 100%
> correct results from catalog accesses worth having when the real world
> speed of it is not substantially very good? (Whether its x1000000
> times slower or not is not relevant if it is still fast enough).

That argument is just nonsense AFAICT. Yes, 2.5 s to drop 10000
functions is probably fine, but that is an artificial test case whose
only real interest is to benchmark what a change in SnapshotNow scans
might cost us. In the real world it's hard to guess what fraction of a
real workload might consist of such scans, but I suspect there are some
where a significant increase in that cost might hurt. So in my mind the
point of the exercise is to find out how much the cost increased, and
I'm just baffled as to why you won't use a benchmark case to, um,
benchmark.

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.

regards, tom lane