On Fri, Aug 18, 2006 at 09:15:59AM +0900, Satoshi Nagayasu wrote:
ITAGAKI Takahiro wrote:
But the method has the above problem. So I suggest to use whether
the right link points to the next adjacent page or not.
if (opaque-btpo_next != P_NONE opaque-btpo_next != blkno + 1)
On Aug 17, 2006, at 4:10 PM, Martijn van Oosterhout wrote:
On Thu, Aug 17, 2006 at 02:54:20PM -0500, Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout
wrote:
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
But the method has the above
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
I think this condition should be regarded as full-fragmented,
but pgstatindex reports that the leaf_fragmentation is 50%.
Presently, fragmentation factor is computed as the code below:
if (opaque-btpo_next != P_NONE
On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout wrote:
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
I think this condition should be regarded as full-fragmented,
but pgstatindex reports that the leaf_fragmentation is 50%.
Presently, fragmentation
On Thu, Aug 17, 2006 at 02:54:20PM -0500, Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout wrote:
On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
But the method has the above problem. So I suggest to use whether
the right link points
ITAGAKI Takahiro wrote:
But the method has the above problem. So I suggest to use whether
the right link points to the next adjacent page or not.
if (opaque-btpo_next != P_NONE opaque-btpo_next != blkno + 1)
stat-fragments++;
Well, in that way, following two conditions,
[1]
Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Well, in that way, following two conditions,
[1] [x] [2] [y] [3]
and
[3] [x] [2] [y] [1]
will be calculated as same fragmentation ratio(100%), I can't agree
with that, because both will generate different costs while index scan
in the real
ITAGAKI Takahiro wrote:
Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Well, in that way, following two conditions,
[1] [x] [2] [y] [3]
and
[3] [x] [2] [y] [1]
will be calculated as same fragmentation ratio(100%), I can't agree
with that, because both will generate different costs while
Satoshi Nagayasu [EMAIL PROTECTED] wrote:
I hope you to write how to interpret the framgentation (and other) info
in README. In my understanding, I'll write You'd better do REINDEX when
you see the fragmentation is greater than 50% under the present
calculation method.
I can't
ITAGAKI Takahiro wrote:
Suppose a simple update case, for example, the accounts table in pgbench.
The default fillfactor of btree indexes is 90%, so the leaf pages are
fully split after we update 10-20% of tuples. But pgstatindex reports
the fragmentation is 50% in such condition, but I think
Hi Nagayasu san and folks,
I have a question about pgstatindex.
Satoshi Nagayasu [EMAIL PROTECTED] wrote:
Attached patch has been cleaned up,
and modified to be able to work with CVS HEAD.
Index leaf pages are ordered just after REINDEX.
[1] [2] [3]
After full-split, they will be the
11 matches
Mail list logo