Re: Patch: fix lock contention for HASHHDR.mutex

On 11 December 2015 at 16:14, Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru
> wrote:

> I see your point, but I would like to clarify a few things.
>
> 1. Do we consider described measurement method good enough to conclude
> that sometimes PostgreSQL really spends 3 ms in a spinlock (like a RTT
> between two Internet hosts in the same city)? If not, what method
> should be used to approve or disapprove this?
>

Timing things seems fine. You may have located an important issue.

> 2. If we agree that PostgreSQL does sometimes spend 3 ms in a spinlock
> do we consider this a problem?
>

Probably, but then Tom didn't question 1 or 2. What he questioned was your
fix.

> 3. If we consider this a problem, what method is considered appropriate
> to find a real reason of such behaviour so we could fix it?
>

The problem you identify is in only one place, yet your fix changes many
parts of the code. Why is that the best fix out of the many possible ones?
Why would such a change be acceptable?

I personally don't know the answers to those questions. It would be
wonderful if somebody else would structure our lives such that all we had
to do was find simple answers, but that isn't the way life is. You ask for
a chain of logical thought, but it is for you to create one, somehow:
patches are default-reject, not committer-explain-why-reject.

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