Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHncf-0000XC-DC for pgsql-bugs@arkaria.postgresql.org; Mon, 05 Jun 2017 08:44:25 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dHnce-0001Uo-J7 for pgsql-bugs@arkaria.postgresql.org; Mon, 05 Jun 2017 08:44:24 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dHnbx-0000Ek-KO for pgsql-bugs@postgresql.org; Mon, 05 Jun 2017 08:43:41 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dHnbv-0007Hs-1o for pgsql-bugs@postgresql.org; Mon, 05 Jun 2017 08:43:40 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7C8F12036B; Mon, 5 Jun 2017 04:43:38 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 05 Jun 2017 04:43:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=WHsg79BupTSaXlfteX vQNEGQLKfsHt6jIxY+rjS2Weg=; b=lzP6I2Q7QSNe6lKPnHhzO79tQK5MeEEcN4 H/gO3Vl1WdJO/1VUP5TRc++EvyCt+TE6aV23aWYTVjJ0fwGNnp8EXULnkjKGS4fU je9KZdNkiZjmMb56OpVijMpRQkfxH5s3Uy4afUgQyKRsU7qDoCXShwAeRxW+XmkF qqtISzgsUxMts4L+Vnw/Xk2rU5LxZMUlVrBTiJKn7CBSgUZy7R3pBUNFM4puQNyd uMbRmQcSqs19iyPKTnllXLvvoitWkYReHJfHfZh/q5yiBFBnTEcQUaM+E6yNFWWh bDVJgWY3GgHmFNkVkBrDZQpmn0dgZ6bCKvC//w6jT8WNd8Fn/jiQ== X-ME-Sender: X-Sasl-enc: pMK+KELvpzexzDagF95EELGJ10CzYWipFs79KvqlKgYH 1496652218 Received: from intern.anarazel.de (unknown [136.24.76.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 3639C24407; Mon, 5 Jun 2017 04:43:38 -0400 (EDT) Date: Mon, 5 Jun 2017 01:43:37 -0700 From: Andres Freund To: Heikki Linnakangas Cc: pgsql-bugs@postgresql.org, chjischj@163.com Subject: Re: BUG #14687: pg_xlogdump does only count "main data" for record length and leading to incorrect statistics Message-ID: <20170605084337.fvm4nfa6c5hu3j2b@alap3.anarazel.de> References: <20170603165939.1436.58887@wrigleys.postgresql.org> <20170604231012.rkhlpf5hqiiszwmb@alap3.anarazel.de> <20170605022511.imow2t2ojsbauk72@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org On 2017-06-05 11:23:43 +0300, Heikki Linnakangas wrote: > On 06/05/2017 05:25 AM, Andres Freund wrote: > > Hi Heikki, > > Do you see any better way to get at the !fpi len than to iterate over > > the blocks and sum up the image length? It's not really accurate to > > display len (rec/tot) as total-fpi, total, but I don't have a better > > backward-compatible idea? Actually, I don't even have a better idea for > > master, so maybe it's ok as proposed? > > Your patch seems OK to me. Defining non-FPI size as (total_len - fpi_len) > seems correct to me, I'm not sure what other definition you could have. I'm not sure, that's why I chose the above. But you could argue that the block ids etc. shouldn't be counted as part of either, or that the previous displaying of record len / total len doesn't make much sense anymore. Greetings, Andres Freund -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs