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 1gr8qW-0003id-CT for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Feb 2019 22:05:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gr8qU-0007HZ-T9 for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Feb 2019 22:05:34 +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 1gr8qU-0007Ds-LS for pgsql-hackers@lists.postgresql.org; Tue, 05 Feb 2019 22:05:34 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gr8qQ-0004RF-NU for pgsql-hackers@lists.postgresql.org; Tue, 05 Feb 2019 22:05:33 +0000 Received: by mail-wr1-x444.google.com with SMTP id v13so5423291wrw.5 for ; Tue, 05 Feb 2019 14:05:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=YL4lW9A3eUfKYQ9G2VZdkvfEZ0ZxQIT70JAfHqWJChc=; b=NgPBalb6hBjHmNt6TA6v9VEao4D791mQOr4Xvm7iIw8i+sDlPyJdjLv9xOnTbzPR0b J2Akozg0LMQ8mqlyIIJBQRc6UA8XUfQniUiTs91JhkqbtglxOPLe8k7JP9K3qJqM4QrG lkVxS4yOMq6woJ903nutdFzQF3Lhu5mMGd6DeTRpuYoqm4rsLsI1eHurfHHNtzzuICas uVu5YMw64QDihyDx/EzE/V4bbLETgCJMlQczWnAJnT9QmoP8aALUVpXNRPPrxhpB3nOf HKsog1l1eqytCAhYqnVZPDyaLkx2K4HdDkZM9KtgZeyvQchzLxSqgGlWvXlVBz/5KnJ2 hc5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=YL4lW9A3eUfKYQ9G2VZdkvfEZ0ZxQIT70JAfHqWJChc=; b=NDq3RI7s1GwzoNTYVIiQPVAT8WmDq6VzzlPL4+GGAsvgbMGBTt6AebaISxPLqO5j3w 8XFHTY0LN2h8f4wd7KVAcYrkSsUZkt0JBhsZ7dKkzK8ZLyXejoc4QCbwoHIGRAyU3XI6 mHiRE5aJjb516z4nqiRzsITGyUjllco/PNZ+9HdT1LSGKakrOohRj19RZQvEMyBA1S5B gsPEuUYo5LKrF8z1oK8tjBR7rLVuhWvd2sW0ldunHJ18y8QrRRhkyE3g6h7qsqF727UA UpN6I2PCK3QOeaCPEop24m03caOYQv7FZ6FI8uqM4RXorTV05Vu1B7HAjJY6XrNGr2f9 o7xA== X-Gm-Message-State: AHQUAuagaapOwoVq7kn7ta3u4yfNrDFNr0Q9uXyupJJ3yo+xs0aGpyoY YFAaEJGnvbYJtby2jEDn3KzKxA== X-Google-Smtp-Source: AHgI3IbykXEA6/qCEFPrg5GO2xRcHt9d7tsOOra9AZcHJVnFgpxbeVtsu/NIdPYBG2eaPvYhbjFf9w== X-Received: by 2002:adf:f052:: with SMTP id t18mr5575497wro.112.1549404329558; Tue, 05 Feb 2019 14:05:29 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([212.145.226.69]) by smtp.gmail.com with ESMTPSA id x22sm5662988wmj.40.2019.02.05.14.05.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 05 Feb 2019 14:05:29 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 00D1A1238F8; Tue, 5 Feb 2019 19:05:26 -0300 (-03) Date: Tue, 5 Feb 2019 19:05:26 -0300 From: Alvaro Herrera To: Tomas Vondra Cc: Bruce Momjian , "andres@anarazel.de" , Robert Haas , Tom Lane , Kyotaro HORIGUCHI , "Ideriha, Takeshi" , "pgsql-hackers@lists.postgresql.org" , "Tsunakawa, Takayuki" , "michael.paquier@gmail.com" , "david@pgmasters.net" , "craig@2ndquadrant.com" Subject: Re: Protect syscache from bloating with negative cache entries Message-ID: <20190205220526.GA1442@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0d3806bf-5087-a75f-3592-ee1d508a79db@2ndquadrant.com> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Feb-05, Tomas Vondra wrote: > I don't think we need to remove the expired entries right away, if there > are only very few of them. The cleanup requires walking the hash table, > which means significant fixed cost. So if there are only few expired > entries (say, less than 25% of the cache), we can just leave them around > and clean them if we happen to stumble on them (although that may not be > possible with dynahash, which has no concept of expiration) of before > enlarging the hash table. I think seqscanning the hash table is going to be too slow; Ideriha-san idea of having a dlist with the entries in LRU order (where each entry is moved to head of list when it is touched) seemed good: it allows you to evict older ones when the time comes, without having to scan the rest of the entries. Having a dlist means two more pointers on each cache entry AFAIR, so it's not a huge amount of memory. > So if we want to address this case too (and we probably want), we may > need to discard the old cache memory context someho (e.g. rebuild the > cache in a new one, and copy the non-expired entries). Which is a nice > opportunity to do the "full" cleanup, of course. Yeah, we probably don't want to do this super frequently though. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services