[progress Communities] [progress Openedge Abl] Forum Post: Re: High Create / Delete Tables...

  • Thread starter Thread starter gus
  • Start date Start date
Status
Not open for further replies.
G

gus

Guest
Dmitri, I agree. I was not suggesting to always use 256. I was trying to explain how things work and using 256 as an example. One reason I use it as an example was to show that it should not be used at all for 4k blocks because the overhead from 256 records eats too much space. In most cases, I think 64 or 128 are reasonable choices. 1, 2, 4, 8 are /almost never/ reasonable choices. Doing too much analysis and sorting you tables into amny row sized buckets is pointless waste of time. Much more important is to get the create and toss limits right. wrong create limit leads either to fragmentaton or wasted space. wrong toss limit leads to long rm chains and slow space allocations. regards, gus (gus@progress.com) "A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable." -- Leslie Lamport > On May 5, 2016, at 2:25 PM, Dmitri Levin wrote: > > Update from Progress Community [https://community.progress.com/] > > Dmitri Levin [https://community.progress.com/members/broder] > > With "one size fits all" RPB approach I believe we look at database from only one side, i.e. how to effectively fit records into blocks. And 128 (or 256) RPB is the most likely answer. > > However if we look at it from the performance side we will see that the choice of a slightly lower RBP will help to avoid record fragmentation. I believe George wrote that "fragmentation happen to the last record that we put into a block". > > We can avoid/limit fragmentation by putting table into area with lower RPB or probably better approach is to set a bigger Create limit on a table itself. And changing Create limit is much more easy than to move table in a different area. So I am not actually advising to put table into areas with appropriate RPBs to avoid fragmentation, but only pointing out that it could help to avoid fragmentation. > > View online [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/24745/86061#86061] > > You received this notification because you subscribed to the forum. To unsubscribe from only this thread, go here [https://community.progress.com/community_groups/openedge_rdbms/f/18/t/24745/mute]. > > Flag [https://community.progress.com/community_groups/openedge_rdbms/f/18/p/24745/86061?AbuseContentId=f9f6d6e2-1f89-4137-aa12-c83e52fa7a80&AbuseContentTypeId=f586769b-0822-468a-b7f3-a94d480ed9b0&AbuseFlag=true] this post as spam/abuse.

Continue reading...
 
Status
Not open for further replies.
Back
Top