Re: ALTER TABLE lock strength reduction patch is unsafe
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-01-02T17:09:16Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add bytea_agg, parallel to string_agg.
- d5448c7d31b5 9.2.0 cited
-
Fix ALTER TABLE ONLY .. DROP CONSTRAINT.
- c0f03aae0469 9.2.0 cited
Attachments
- snapshotnow_consistent.v4.patch (text/x-patch) patch v4
On Tue, Dec 20, 2011 at 4:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Noah Misch <noah@leadboat.com> writes: >> On Mon, Dec 19, 2011 at 11:13:57PM -0500, Tom Lane wrote: >>> ... but this performance test seems to me to be entirely misguided, >>> because it's testing a situation that isn't going to occur much in the >>> field, precisely because the syscache should prevent constant reloads of >>> the same syscache entry. > >>> [ideas for more-realistic tests] > >> Granted, but I don't hope to reliably measure a change in a macro-benchmark >> after seeing a rickety 2% change in a micro-benchmark. > > No, I'm not sure about that at all. In particular I think that > CatalogCacheFlushCatalog is pretty expensive and so the snapshot costs > could be a larger part of a more-realistic test. Attached patch makes SnapshotNow into an MVCC snapshot, initialised at the start of each scan iff SnapshotNow is passed as the scan's snapshot. It's fairly brief but seems to do the trick. Assuming that is the right approach, some timings 10,000 functions individually Create 15.7s 14.3s 14.8s 14.8s Drop 11.9s 11.7 11.6s 12.0s 10,000 functions in a schema Create ... same ... Drop Cascade 2.5s That seems OK to me. Any feedback? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services