Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1cym-00056B-3X for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 20:17:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h1cyj-0006yi-SQ for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Mar 2019 20:17:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1cyj-0006yb-LH for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 20:17:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h1cyh-0005o2-PR for pgsql-hackers@lists.postgresql.org; Wed, 06 Mar 2019 20:17:25 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x26KHBNo001753; Wed, 6 Mar 2019 15:17:11 -0500 From: Tom Lane To: Robert Haas cc: Kyotaro HORIGUCHI , Andres Freund , "Tsunakawa, Takayuki" , Alvaro Herrera , Tomas Vondra , Bruce Momjian , "Ideriha, Takeshi" , PostgreSQL Hackers , Michael Paquier , David Steele , Craig Ringer Subject: Re: Protect syscache from bloating with negative cache entries In-reply-to: References: <20190225.152653.211323929.horiguchi.kyotaro@lab.ntt.co.jp> <20190301.173245.25820912.horiguchi.kyotaro@lab.ntt.co.jp> Comments: In-reply-to Robert Haas message dated "Wed, 06 Mar 2019 13:09:15 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1751.1551903431.1@sss.pgh.pa.us> Date: Wed, 06 Mar 2019 15:17:11 -0500 Message-ID: <1752.1551903431@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > OK, so this is getting simpler, but I'm wondering why we need > dlist_move_tail() at all. It is a well-known fact that maintaining > LRU ordering is expensive and it seems to be unnecessary for our > purposes here. Yeah ... LRU maintenance was another thing that used to be in the catcache logic and was thrown out as far too expensive. Your idea of just using a clock sweep instead seems plausible. regards, tom lane