Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lU6c0-0005uv-Ll for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Apr 2021 11:44:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lU6bz-0001M2-IG for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Apr 2021 11:44:43 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lU6bz-0001Lu-7b for pgsql-hackers@lists.postgresql.org; Wed, 07 Apr 2021 11:44:43 +0000 Received: from forwardcorp1p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b6:217]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lU6bv-00018K-8Z for pgsql-hackers@postgresql.org; Wed, 07 Apr 2021 11:44:42 +0000 Received: from sas1-ec30c78b6c5b.qloud-c.yandex.net (sas1-ec30c78b6c5b.qloud-c.yandex.net [IPv6:2a02:6b8:c14:2704:0:640:ec30:c78b]) by forwardcorp1p.mail.yandex.net (Yandex) with ESMTP id AFD5D2E16CF; Wed, 7 Apr 2021 14:44:34 +0300 (MSK) Received: from sas2-d40aa8807eff.qloud-c.yandex.net (sas2-d40aa8807eff.qloud-c.yandex.net [2a02:6b8:c08:b921:0:640:d40a:a880]) by sas1-ec30c78b6c5b.qloud-c.yandex.net (mxbackcorp/Yandex) with ESMTP id vST7AyJDzM-iY0qnBhI; Wed, 07 Apr 2021 14:44:34 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1617795874; bh=xBplgBcx4wpGjjbZW72hyifGTJnFiRSP16jMlMhatYs=; h=To:Message-Id:References:Date:Subject:Cc:In-Reply-To:From; b=PG6o8+WiWui+AYhv/nFqQeWu/a/V4KE0uP2/82j1j7In7+OGvRJjsKragEhmFYSy9 0pOVPii93x6H9tGLvwMMwtb16J9wuyJEA9rAu0cQeBXNyDirPQzAdNMwyuemfE+Adn newUlfxLic8yl+3K5hcLoD3iU1pN3ot+6mmPlLik= Authentication-Results: sas1-ec30c78b6c5b.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from unknown (unknown [2a02:6b8:0:450c:159:ef22:a673:1692]) by sas2-d40aa8807eff.qloud-c.yandex.net (smtpcorp/Yandex) with ESMTPSA id 9CZMPdEyg2-iXpKk68n; Wed, 07 Apr 2021 14:44:33 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) 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 In-Reply-To: Date: Wed, 7 Apr 2021 14:44:32 +0300 Cc: Gilles Darold , Tomas Vondra , Tomas Vondra , Alexander Korotkov , Anastasia Lubennikova , Daniel Gustafsson , Kyotaro Horiguchi , pgsql-hackers Content-Transfer-Encoding: quoted-printable Message-Id: References: <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> <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> <1E3DD5BF-A54E-4203-86C5-94C9EFA0E095@yandex-team.ru> <04ae150b-6442-148a-bb23-77082f6fca1d@darold.net> <3768803E-4794-409D-88D2-C3EF7CA1B7FC@yandex-team.ru> <75B95FDD-2BE0-4525-8BDD-FC67C8BCBD53@yandex-team.ru> <88CB7042-6181-4EF4-8B25-61EC5E5725D4@yandex-team.ru> <018EF641-FC9D-4BA9-A458-6842E27E91C2@yandex-team.ru> <27D90FFC-B897-4BC5-B4F5-9047B9886AA3@yandex-team.ru> To: Thomas Munro X-Mailer: Apple Mail (2.3608.120.23.2.4) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > 7 =D0=B0=D0=BF=D1=80. 2021 =D0=B3., =D0=B2 08:59, Thomas Munro = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0= ): >=20 > The remaining thing that bothers me about this patch set is that there = is still a linear search in the replacement algorithm, and it runs with = an exclusive lock. That creates a serious problem for large caches that = still aren't large enough. I wonder if we can do something to improve = that situation in the time we have. I considered a bunch of ideas but = could only find one that fits with slru.c's simplistic locking while = tracking recency. What do you think about a hybrid of SLRU and random = replacement, that retains some characteristics of both? You could think = of it as being a bit like the tournament selection of the genetic = algorithm, with a tournament size of (say) 8 or 16. Any ideas on how to = evaluate this and choose the number? See attached. > = Maybe instead of fully associative cache with random replacement we = could use 1-associative cache? i.e. each page can reside only in one spcific buffer slot. If there's = something else - evict it. I think this would be as efficient as RR cache. And it's soooo fast. Best regards, Andrey Borodin.=