Date: Fri, 18 Dec 2015 08:10:09 +0300
From: Aleksander Alekseev <a.alekseev@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, "pgsql-hackers@postgresql.org"
 <pgsql-hackers@postgresql.org>
Subject: Re: Patch: fix lock contention for HASHHDR.mutex
Message-ID: <20151218081009.34ea4c04@fujitsu>
In-Reply-To: 
 <CA+Tgmob1-7=Bh21LyLXk7Yst1nzcA1P=rv0UKq1zH+A9PVehrg@mail.gmail.com>
References: <20151211170001.78ded9d7@fujitsu>
 <20151215122513.GC17724@alap3.anarazel.de>
 <CA+TgmoavsNuBNQf6ROn020F6g9gXJjtMrSkSFZ=RL1t2eJHQ5Q@mail.gmail.com>
 <20151217151418.GB2224@awork2.anarazel.de>
 <20151217190342.07e4533a@fujitsu>
 <CA+Tgmob1-7=Bh21LyLXk7Yst1nzcA1P=rv0UKq1zH+A9PVehrg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

> Oh, that's an interesting idea.  I guess the problem is that if the
> freelist is unshared, then users might get an error that the lock
> table is full when some other partition still has elements remaining.

True, but I don't believe it should be a real problem assuming we have
a strong hash function. If user get such an error it means that
database is under heavy load and there is not much more free elements
in other tables either. This particular user didn't get lucky, some
other will. Anyway administrator should do something about it -
fight DDoS attack, tune database parameters, etc.

> 3.5-4 more TPS, or 3.5 times more TPS?  Can you share the actual
> numbers?

Oops, 3.5-4 _times_ more TPS, i.e. 2206 TPS vs 546 TPS.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers