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 →
  1. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

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