Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aWTe2-0004ed-3p for pgsql-docs@arkaria.postgresql.org; Thu, 18 Feb 2016 18:49:42 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aWTe1-0007Cn-Hu for pgsql-docs@arkaria.postgresql.org; Thu, 18 Feb 2016 18:49:41 +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) (envelope-from ) id 1aWTe0-0007Bk-7g; Thu, 18 Feb 2016 18:49:40 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aWTdx-0004RS-KI; Thu, 18 Feb 2016 18:49:38 +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 u1IInVT0010923; Thu, 18 Feb 2016 13:49:31 -0500 From: Tom Lane To: Peter Geoghegan cc: =?UTF-8?B?5aSn5aGa5oay5Y+4?= , pgsql-docs@postgresql.org, Pg Hackers Subject: Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ? In-reply-to: References: <56C5B2C7.7010604@nttcom.co.jp> <31925.1455817248@sss.pgh.pa.us> <377.1455818470@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Thu, 18 Feb 2016 10:35:21 -0800" Date: Thu, 18 Feb 2016 13:49:31 -0500 Message-ID: <10922.1455821371@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-docs Precedence: bulk Sender: pgsql-docs-owner@postgresql.org Peter Geoghegan writes: > That's odd. Having taken a quick look at pgstatindex_impl(), I dislike > that it counts the root separately from internal pages. That's not how > they're actually presented and understood in the code. Yeah, that seems a bit strange to me as well. Should we change it to count the root as an internal page, or is that going too far? Note that it's already the case that in a one-page index (root is also a leaf), the root will be included in the leaf_pages count. So it sure seems inconsistent that it's not included in the internal_pages count when it's not a leaf. > It's also possible to have more than one root page, since we do a scan > in physical order, which the code considers. There could be a fast > root and a true root. Looks like one is counted as deleted, though: Well, actually, since we don't have write lock on the index it'd be possible to see zero or multiple roots because the root's location changes. That's already mentioned in the documentation, if somewhat obliquely. regards, tom lane -- Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs