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

From Simon Riggs
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id CA+U5nMJMcwHfJ6aGrrWD+bm4+Sd3HRU9=iL5P=wta2GfR_cwKQ@mail.gmail.com
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
On Tue, Jan 3, 2012 at 3:24 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> I feel like the first thing we should be doing here is some
> benchmarking.  If we change just the scans in dependency.c and then
> try the test case Tom suggested (dropping a schema containing a large
> number of functions), we can compare the patched code with master and
> get an idea of whether the performance is acceptable.

Yes, I've done this and it takes 2.5s to drop 10,000 functions using
an MVCC snapshot.

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).

Anybody with that many DDL statements probably cares about doing
various operations with lower lock levels.

Fastpath locking will slow down DDL but we didn't measure the
performance slow down there. We understood the benefit and were
willing to pay the price.

So I'll proceed for now with the patch, which isn't as simple as you think.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: patch: ALTER TABLE IF EXISTS
Next
From: Noah Misch
Date:
Subject: Re: Patch to allow users to kill their own queries