Re: reducing the overhead of frequent table locks - now, with WIP patch - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: reducing the overhead of frequent table locks - now, with WIP patch
Date
Msg-id BANLkTikizW2KXnYAfboRjQW4PyD4XtariA@mail.gmail.com
Whole thread Raw
In response to Re: reducing the overhead of frequent table locks - now, with WIP patch  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: reducing the overhead of frequent table locks - now, with WIP patch
List pgsql-hackers
On Mon, Jun 6, 2011 at 11:19 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 06.06.2011 12:40, Simon Riggs wrote:
>>
>> On Sat, Jun 4, 2011 at 5:55 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>>>
>>> Simon Riggs<simon@2ndquadrant.com>  writes:
>>>>
>>>> The approach looks sound to me. It's a fairly isolated patch and we
>>>> should be considering this for inclusion in 9.1, not wait another
>>>> year.
>>>
>>> That suggestion is completely insane.  The patch is only WIP and full of
>>> bugs, even according to its author.  Even if it were solid, it is way
>>> too late to be pushing such stuff into 9.1.  We're trying to ship a
>>> release, not find ways to cause it to slip more.
>>
>> In 8.3, you implemented virtual transactionids days before we produced
>> a Release Candidate, against my recommendation.
>
> FWIW, this bottleneck was not introduced by the introduction of virtual
> transaction ids. Before that patch, we just took the lock on the real
> transaction id instead.

Of course it wasn't. You've misunderstood completely.

My point was that we have in the past implemented performance changes
to increase scalability at the last minute, and also that our personal
risk perspectives are not always set in stone.

Robert has highlighted the value of this change and its clearly not
beyond our wit to include it, even if it is beyond our will to do so.


>> The fact that you disagree with me does not make me insane.
>
> You are not insane, even if your suggestion is.

LOL. Your logic is still poor though. :-)

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: BLOB support
Next
From: Nick Raj
Date:
Subject: Different execution time for same plan