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.92) (envelope-from ) id 1j7oum-0008Mw-LB for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 23:19: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 1j7oul-0001AJ-GD for pgsql-hackers@arkaria.postgresql.org; Fri, 28 Feb 2020 23:19:27 +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 1j7oul-0001AB-7V for pgsql-hackers@lists.postgresql.org; Fri, 28 Feb 2020 23:19:27 +0000 Received: from mail-yw1-xc42.google.com ([2607:f8b0:4864:20::c42]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j7oui-00048f-Iq for pgsql-hackers@postgresql.org; Fri, 28 Feb 2020 23:19:26 +0000 Received: by mail-yw1-xc42.google.com with SMTP id d206so4970286ywa.12 for ; Fri, 28 Feb 2020 15:19:24 -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=TKUwxMKMednJnUQhKRABA0ih96OG9TA5f4KapU4PhYk=; b=eBMZz1kFXbuATHeBORe675rQpQiV1mqaexmuarByxbSfrSK2fuV/lM+tn7u/C/+68e nzni99yOFJTJHxyawRsoCRUJlwTBlX0ycRax8Z14GdJugv1E4hDBjvAdOVTu3TAbVw6e hXE9WMjzZgiwIbxHh+ZdwPzxeCgpm6OO5PKkfQG5CjcZmjWlhfMkzUEXEmOeTe2HZIMh gpqfRCjDDCq9QZxD7Igit0Yp7FCS+HcF51dVLspREKduS9MHq63K7Z+NCrUEE7EMmlA0 mJlSxUrjhbjCLoQM59lDODYUOdHe9ZH9jHUE5yceVJUPw33bn/RnuaisA04wjD5avJXP KEnQ== 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=TKUwxMKMednJnUQhKRABA0ih96OG9TA5f4KapU4PhYk=; b=fYt4GgTwRWwIABCbp/FJmDR9utmzEe4uvnRIJNXWib7SxWQjjES8CiQEbX92cW8VAq QqRSVtPIN77i163qDVTSuEcPeWfPMP8qWIETn3M3Cqb36xciy34vwrgDMaCsvxiE/dWn mZDRgSytDXncO83/4h5rY3LYFfqv5pB+bV0J6IafXVdlzbYwtrHICFIDfq37SYHaya5C QBEfUcE2YRQ7O1mQhva868fukzbXudflT+8JFcvQ7mzCnK0idWhq0KugTmWF83URdWKZ AJPWuRtE2X8OPonhVrzHTdSDzbSJUNcsXUw9TtetJMJq7iLGCfPFjdojQ8FnATsF10eO JfdQ== X-Gm-Message-State: APjAAAV5vi+z2KgrWybnxPi8aHe18I1RrcIfYCXUsKIAQg0WowbC/AFs eVCSGHCZyuMOti91FzLqG2Jykw== X-Google-Smtp-Source: APXvYqzG4afveTjSvv+FJDzSV63/SEozXZw1+MO4HcrglRHav5AK68diLkLprDINW/mW8anr+Wm1Gg== X-Received: by 2002:a0d:e382:: with SMTP id m124mr7147666ywe.313.1582931963086; Fri, 28 Feb 2020 15:19:23 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([199.116.115.139]) by smtp.gmail.com with ESMTPSA id a12sm1479465ywm.0.2020.02.28.15.19.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 28 Feb 2020 15:19:22 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 920F330016F; Fri, 28 Feb 2020 20:19:18 -0300 (-03) Date: Fri, 28 Feb 2020 20:19:18 -0300 From: Alvaro Herrera To: Tomas Vondra Cc: Masahiko Sawada , "tsunakawa.takay@fujitsu.com" , "pgsql-hackers@postgresql.org" Subject: Re: SLRU statistics Message-ID: <20200228231918.GA30292@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200121135614.vt4cpuzwiyarzfca@development> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Jan-21, Tomas Vondra wrote: > On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote: > > I've not tested the performance impact but perhaps we might want to > > disable these counter by default and controlled by a GUC. And similar > > to buffer statistics it might be better to inline > > pgstat_count_slru_page_xxx function for better performance. > > Hmmm, yeah. Inlining seems like a good idea, and maybe we should have > something like track_slru GUC. I disagree with adding a GUC. If a performance impact can be measured let's turn the functions to static inline, as already proposed. My guess is that pgstat_count_slru_page_hit() is the only candidate for that; all the other paths involve I/O or lock acquisition or even WAL generation, so the impact won't be measurable anyhow. We removed track-enabling GUCs years ago. BTW, this comment: /* update the stats counter of pages found in shared buffers */ is not strictly true, because we don't use what we normally call "shared buffers" for SLRUs. Patch applies cleanly. I suggest to move the page_miss() call until after SlruRecentlyUsed(), for consistency with the other case. I find SlruType pretty odd, and the accompanying "if" list in pg_stat_get_slru() correspondingly so. Would it be possible to have each SLRU enumerate itself somehow? Maybe add the name in SlruCtlData and query that, somehow. (I don't think we have an array of SlruCtlData anywhere though, so this might be a useless idea.) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services