Re: [HACKERS] pgstattuple extension for indexes

2006-08-23 Thread Jim C. Nasby
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)

Re: [HACKERS] pgstattuple extension for indexes

2006-08-22 Thread Jim Nasby
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Martijn van Oosterhout
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Jim C. Nasby
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Martijn van Oosterhout
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Satoshi Nagayasu
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]

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread ITAGAKI Takahiro
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Satoshi Nagayasu
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread ITAGAKI Takahiro
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-17 Thread Satoshi Nagayasu
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

Re: [HACKERS] pgstattuple extension for indexes

2006-08-16 Thread ITAGAKI Takahiro
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