Hi all,
It seems that description of index_size that is returned by pgstatindex() is
wrong.
The document says "Total number of pages in index".
But it looks like the number of bytes is stored in index_size.
The document page:
http://www.postgresql.org/docs/9.5/interactive/pgstattuple.html
=?UTF-8?B?5aSn5aGa5oay5Y+4?= writes:
> It seems that description of index_size that is returned by pgstatindex() is
> wrong.
> The document says "Total number of pages in index".
> But it looks like the number of bytes is stored in index_size.
Hmm, you're right, because what the code does is
On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote:
> I think this is a bug and we ought to fix the code to include the
> metapage in the reported index_size. Thoughts?
I tend to agree, but I think you should note that specifically in the
documentation. I'm in favor of tools like pgstattuple and pa
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 9:40 AM, Tom Lane wrote:
>> I think this is a bug and we ought to fix the code to include the
>> metapage in the reported index_size. Thoughts?
> I tend to agree, but I think you should note that specifically in the
> documentation. I'm in favor
On Thu, Feb 18, 2016 at 10:01 AM, Tom Lane wrote:
> Yeah ... the numbers already appear not to add up because the root page
> is counted in index_size but not any other column, so there's already
> something worthy of explanation there. Maybe something like "The reported
> index_size will normall
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
On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote:
> 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?
I think we should change it. It seems like a bug to me. I've had the
same point come up ("leaf-ness/internal-ne
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 10:49 AM, Tom Lane wrote:
>> 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?
> I think we should change it. It seems like a bug to me.
Me too. Is it enough b
I vote back patch. Subtle differences between the branches should be
avoided.
--
Peter Geoghegan
I wrote:
> Peter Geoghegan writes:
>> I think we should change it. It seems like a bug to me.
> Me too. Is it enough bug-like to be something to back-patch, or should
> we just change it in HEAD?
Actually, there's a significantly worse bug here: I just realized that the
page type tests are done
On Thu, Feb 18, 2016 at 11:52 AM, Tom Lane wrote:
> It looks like this was done correctly to begin with, and I broke it in
> d287818eb514d431b1a68e1f3940cd958f82aa34. Not sure what I was thinking :-(
I think that you might not have simply changed the order in a totally
misguided way back in 2008
Peter Geoghegan writes:
> I think that the P_ISLEAF() instrumentation of free space and
> fragments might still need to happen for deleted and/or half dead
> pages.
Don't see why; the documentation and field names clearly imply that those
numbers are accumulated only over leaf pages. I certainly
On Thu, Feb 18, 2016 at 3:06 PM, Tom Lane wrote:
> Don't see why; the documentation and field names clearly imply that those
> numbers are accumulated only over leaf pages.
Then I guess what might be lacking is a delineation of what a leaf
page is for the purposes of pgstatindex().
> I certainly
Peter Geoghegan writes:
> Why would dead pages not get traversed by scans?
Because they've been removed from the right-link/left-link chains.
regards, tom lane
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://
I have created the attached doc patch to update effective_io_concurrency
to more accurately cover SSDs.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscripti
On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote:
> Because they've been removed from the right-link/left-link chains.
That isn't the same thing as being inaccessible by scans, clearly
(just what you call the "leaf scan sequence"). Besides, half-dead
pages still have right-link/left-link chains, a
Peter Geoghegan writes:
> On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane wrote:
>> Because they've been removed from the right-link/left-link chains.
> That isn't the same thing as being inaccessible by scans, clearly
> (just what you call the "leaf scan sequence").
Only a physical-order scan, ie va
17 matches
Mail list logo
