Re: Performance degradation in commit ac1d794

On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> > Putting it on the open items list sounds good to me.
>>
>> Well, OK, I've done that then. I don't really agree that it's not a
>> problem; the OP said he saw a 3x regression, and some of my colleagues
>> doing benchmarking are complaining about this commit, too. It doesn't
>> seem like much of a stretch to think that it might be affecting other
>> people as well.
>
> Well, I can't do anything about that right now. I won't have the time to
> whip up the new/more complex API we discussed upthread in the next few
> days. So either we go with a simpler API (e.g. pretty much a cleaned up
> version of my earlier patch), revert the postmaster deatch check, or
> somebody else has to take lead in renovating, or we wait...

Well, I thought we could just revert the patch until you had time to
deal with it, and then put it back in. That seemed like a simple and
practical option from here, and I don't think I quite understand why
you and Tom don't like it. I don't have a problem with deferring to
the majority will here, but I would sort of like to understand the
reason for the majority will.

BTW, if need be, I can look for an EnterpriseDB resource to work on
this. It won't likely be me, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company