Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id 23111.1325615081@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: ALTER TABLE lock strength reduction patch is unsafe
Re: ALTER TABLE lock strength reduction patch is unsafe
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane <tgl@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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Robert Haas
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe