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 1itu15-0007Kk-JI for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2020 13:56:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1itu13-0007ZP-Lg for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Jan 2020 13:56: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 1itu13-0007Xh-CJ for pgsql-hackers@lists.postgresql.org; Tue, 21 Jan 2020 13:56:25 +0000 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1itu0v-0003Zc-VP for pgsql-hackers@postgresql.org; Tue, 21 Jan 2020 13:56:24 +0000 Received: by mail-wr1-x430.google.com with SMTP id y11so3291670wrt.6 for ; Tue, 21 Jan 2020 05:56:17 -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:references:mime-version :content-disposition:in-reply-to; bh=fVBRyITeF6FgBXmd7V0yNXraKgHyObfQGuPnZepP8zY=; b=offvq1sjyc8eJLGqNttio7NS6ZY1/yoUMH0FP9MuvqW3/g2Fc5kSf4wLl9GoYxCHHW xz3B0UXp+gNKZd2NBwRVtgwL03hplLjUu3O9CZLNNvgTx82TyOeOJTHrxzoUuWKC+w3g GatDvsYyj17fvBfgOx0I+8vZnknoefFYbZvz8WXHKdWcSvzeWht6l6hRMZ6lvFXTXzbx iI5mTtYQoRbmfzrgrw5f16sD/3Z9X+95iA54/VOwY0dNv1E0pPxk2c55rsoIkoXhNrK4 g8IdPEXbsW/Z7/vFvHZJ7o+9+uPQ/X91Xth8+DNdjk832ms3lz3hK7YNaXtLxTcyWWes pX1Q== 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:references :mime-version:content-disposition:in-reply-to; bh=fVBRyITeF6FgBXmd7V0yNXraKgHyObfQGuPnZepP8zY=; b=PRJHBpoMv4ZZmyf+IqGlHk/43nctqtHtFtntEi6HNvCDJ2kvpBR4zoIm5DOj1vhl6U bpOYHRpYGXBn+cEDVRxz/zm/pfbjTM/4x27EXPyJC7/qn03kyDxUwCRKPMqhbQUKQU8i KMz+X94wFF04a+EIhGPlE8ixuSSGQZal+GN4CFmG3uX2Z157c51pH/lXpv5J4rDcRnp2 mD8D49HsnPYGcLDT9tDZ3KzdQ3K8TpT6Mvl4noEfQkn3Lm5b1LEOq9X/Zv3eQsMPzzEA nTMTwSXKf4pT0dP0P2PeXVKltiSlmPxJ5+146ACUb/rZwRsRrqP8e/IaP9EQUhXBNJvD N/eA== X-Gm-Message-State: APjAAAX5BiUSqsdE/z5f9YOeWQ19sIN9/tLCfLodNK0Nv2BtYfk1cbeN x0UErpYPyHu4mwZoee/HfPK7sw== X-Google-Smtp-Source: APXvYqwW/CE/4hDC1HJJ//bvQKNUr0ZoPsEzEFB9g1loyC2JJsC2Xy/bAaDtVaB1tIQO2kn8KdYx1Q== X-Received: by 2002:adf:f789:: with SMTP id q9mr5652853wrp.103.1579614976653; Tue, 21 Jan 2020 05:56:16 -0800 (PST) Received: from localhost (static-84-42-175-93.net.upcbroadband.cz. [84.42.175.93]) by smtp.gmail.com with ESMTPSA id k8sm51970537wrl.3.2020.01.21.05.56.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jan 2020 05:56:16 -0800 (PST) Date: Tue, 21 Jan 2020 14:56:14 +0100 From: Tomas Vondra To: Masahiko Sawada Cc: "tsunakawa.takay@fujitsu.com" , "pgsql-hackers@postgresql.org" Subject: Re: SLRU statistics Message-ID: <20200121135614.vt4cpuzwiyarzfca@development> References: <20200119143707.gyinppnigokesjok@development> <20200120163754.mbbkbhzaummlo47c@development> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Jan 21, 2020 at 05:09:33PM +0900, Masahiko Sawada wrote: >On Tue, 21 Jan 2020 at 01:38, Tomas Vondra wrote: >> >> On Mon, Jan 20, 2020 at 01:04:33AM +0000, tsunakawa.takay@fujitsu.com wrote: >> >From: Tomas Vondra >> >> One of the stats I occasionally wanted to know are stats for the SLRU >> >> stats (we have couple of those - clog, subtrans, ...). So here is a WIP >> >> version of a patch adding that. > >+1 > >> > >> >How can users take advantage of this information? I think we also need >> >the ability to set the size of SLRU buffers. (I want to be freed from >> >the concern about the buffer shortage by setting the buffer size to its >> >maximum. For example, CLOG would be only 1 GB.) >> > >> >> You're right the users can't really take advantage of this - my primary >> motivation was providing a feedback for devs, benchmarking etc. That >> might have been done with DEBUG messages or something, but this seems >> more convenient. > >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. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services