Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: MultiXact\SLRU buffers configuration
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CA+hUKGKVqrxOp82zER1=XN=yPwV_-OCGAg=ez=1iz9rG+A7Smw@mail.gmail.com>
Date: Sat, 27 Mar 2021 10:31:54 +0500
Cc: Gilles Darold <gilles@darold.net>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
 Daniel Gustafsson <daniel@yesql.se>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <88CB7042-6181-4EF4-8B25-61EC5E5725D4@yandex-team.ru>
References: <a7f1c4e1-1015-92a4-2bd4-6736bd13d03e@postgrespro.ru>
 <20201028013651.de5cj2xadgmba5nf@development>
 <13D8FD63-559A-4737-B7FD-05288D1CEF8B@yandex-team.ru>
 <20201028233243.ygm6yqlynkqpzekr@development>
 <43F3DE92-F236-4EA5-B4D6-39BEF6BD849D@yandex-team.ru>
 <20201029134933.xd4mh2cofuf6tdfz@development>
 <65C1B4BA-D16F-4939-978B-AC8F370F5A5E@yandex-team.ru>
 <9b4d17df-b811-8323-16be-3cab913216d1@enterprisedb.com>
 <A64B924A-B08E-417D-BD3D-D396D722053B@yandex-team.ru>
 <35862787-8b4d-a290-789e-6e12dc6527e8@enterprisedb.com>
 <13F86913-C01B-4983-AE2E-493F5A028280@yandex-team.ru>
 <6ba7eae2-8b0c-0690-11a5-e921e6586180@darold.net>
 <3F5E23A3-6250-486E-9CCA-E2A5B6A28B4F@yandex-team.ru>
 <636f694a-4d69-d6d9-78d1-c88714f3e2e0@darold.net>
 <3319917a-679e-b07d-b194-473552b72082@darold.net>
 <d6f17699-0c18-1a47-8dfb-f52b36fb7c4f@darold.net>
 <D2CC4D64-CA89-411B-96D7-F0A4BF4BB895@yandex-team.ru>
 <b4911e88-9969-aaba-f6be-ed57bd5fec36@darold.net>
 <1E3DD5BF-A54E-4203-86C5-94C9EFA0E095@yandex-team.ru>
 <04ae150b-6442-148a-bb23-77082f6fca1d@darold.net>
 <3768803E-4794-409D-88D2-C3EF7CA1B7FC@yandex-team.ru>
 <CA+hUKGJ4TwipnMDmKdORu4zUo_rofsuu5FQsgV=UHJ3bY38ERw@mail.gmail.com>
 <CA+hUKGK2bkx91=CWRuPqWdXAu2JSS0mDPBh8DNuSeKhy8eOLgg@mail.gmail.com>
 <CA+hUKGL0g+Nmf=2XePaXtw82BkW9CRzoxxXB4gqZOk7tHxNJXg@mail.gmail.com>
 <D330C01E-789A-4DDD-B2B1-4561B8B7F41D@yandex-team.ru>
 <75B95FDD-2BE0-4525-8BDD-FC67C8BCBD53@yandex-team.ru>
 <CA+hUKGKVqrxOp82zER1=XN=yPwV_-OCGAg=ez=1iz9rG+A7Smw@mail.gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/88CB7042-6181-4EF4-8B25-61EC5E5725D4%40yandex-team.ru>
Precedence: bulk


> 27 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2021 =D0=B3., =D0=B2 01:26, Thomas =
Munro <thomas.munro@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=
=D0=B0):
>=20
> On Sat, Mar 27, 2021 at 4:52 AM Andrey Borodin <x4mmm@yandex-team.ru> =
wrote:
>> Some thoughts on HashTable patch:
>> 1. Can we allocate bigger hashtable to reduce probability of =
collisions?
>=20
> Yeah, good idea, might require some study.
In a long run we always have this table filled with nslots. But the keys =
will be usually consecutive numbers (current working set of =
CLOG\Multis\etc). So in a happy hashing scenario collisions will only =
appear for some random backward jumps. I think just size =3D nslots * 2 =
will produce results which cannot be improved significantly.
And this reflects original growth strategy SH_GROW(tb, tb->size * 2).

>> 2. Can we use specialised hashtable for this case? I'm afraid =
hash_search() does comparable number of CPU cycles as simple cycle from =
0 to 128. We could inline everything and avoid hashp->hash(keyPtr, =
hashp->keysize) call. I'm not insisting on special hash though, just an =
idea.
>=20
> I tried really hard to not fall into this rabbit h.... [hack hack
> hack], OK, here's a first attempt to use simplehash,

> Andres's
> steampunk macro-based robinhood template
Sounds magnificent.

> that we're already using for
> several other things
I could not find much tests to be sure that we do not break something...

> , and murmurhash which is inlineable and
> branch-free.
I think pageno is a hash already. Why hash any further? And pages =
accessed together will have smaller access time due to colocation.

>  I had to tweak it to support "in-place" creation and
> fixed size (in other words, no allocators, for use in shared memory).
We really need to have a test to know what happens when this structure =
goes out of memory, as you mentioned below. What would be apropriate =
place for simplehash tests?

> Then I was annoyed that I had to add a "status" member to our struct,
> so I tried to fix that.
Indeed, sizeof(SlruMappingTableEntry) =3D=3D 9 seems strange. Will =
simplehash align it well?


Thanks!

Best regards, Andrey Borodin.=