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-02T21:07:15Z
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
On Mon, Jan 2, 2012 at 8:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Simon Riggs <simon@2ndQuadrant.com> writes: >> On Mon, Jan 2, 2012 at 7:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> But you still didn't. I wanted to know what those numbers were and how >>> they show that there's not a performance regression. Presumably you >>> meant that some were "before" and some "after", but they were not so >>> labeled. > >> All timings were "after" applying the patch. Since all of the tests >> had very acceptable absolute values I didn't test without-patch. > > What is a "very acceptable absolute value", and how do you know it's > acceptable if you don't know what the previous performance was? This > reasoning makes no sense to me at all. I don't need to do things twice before deciding I enjoyed it the first time. A low value showed that there were no problems, to me. If you want to see more or discuss, that's cool, no problem. But no need to beat me up for not guessing correctly the level of rigour that would be acceptable to you. Now I have the first test result of your requirements, I will be able to judge further test results against the required standard. As I've said, this is all invalid now anyway. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services