On Thu, Jan 21, 2016 at 9:03 AM, Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > First of all, why not merge both patches into one? They aren't too big > anyway.
So looking over this patch, it institutes a new coding rule that all shared hash tables must have the same number of partitions, and that number is hard-coded at 128. The number of freelist partitions is also hardcoded at 128. I find this design surprising. First, I would not have expected that we'd need 128 freelist partitions. We get by just fine with only 16 lock manager partitions, at least AFAIK, and there's no reason some future hashtable might not have little enough contention that 16 partitions works just fine. Even for the buffer manager, which does have 128 partitions, I wouldn't assume that we need 128 partitions for the free list just because we need 128 partitions for the locks themselves. It's possible we do, but I'd expect that existing buffer mapping locking might dissipate some of that contention - e.g. if somebody's doing a buffer lookup on a particular partition, they have a shared lock on that partition, so nobody has an exclusive lock to be able to hit the freelist. So: do we have clear evidence that we need 128 partitions here, or might, say, 16 work just fine? Second, I don't see any reason why the number of free list partitions needs to be a constant, or why it needs to be equal to the number of hash bucket partitions. That just seems like a completely unnecessary constraint. You can take the hash value, or whatever else you use to pick the partition, modulo any number you want. I don't really want to increase the number of lock manager partition locks to 128 just for the convenience of this patch, and even less do I want to impose the requirement that every future shared hash table must use an equal number of partitions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
