![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
Hello Folks, Does anyone have an accurate way to calculate the amount of disk spaces needed for tables ? I followed up the method in the section of calculating disk space from Database Administrator's Guide to do the calculation. It seems the calculations are not accuate especialy for BTREE struction in our database(the results of calculations for HEAP are OK). I could get the pages used by a table at present from iitables and compared them with the pages required for this table from my calculations, if there were more than 20% wasted, I reclaimed them by modify <table> to statement, which should reclaim the lost spaces due to many deletions of this table. I compared the pages again after modification and found that there were the same percent of differences. This make me think the way of calculation is not accurate. Can anyone shed a light on my issue and have a better and an accurate way to calculate the amount of disk spaces needed for tables in Ingres. |
#3
| |||
| |||
|
|
Scott wrote: Hello Folks, Does anyone have an accurate way to calculate the amount of disk spaces needed for tables ? ... I don't think you are ever going to get a very accurate calculation because sometimes the per-row overhead is variable. Chip Nickolett has a spreadsheet at http://www.comp-soln.com/var_page.xls that might be of interest. I spent a fair bit of time fiddling with the calculation a couple of years ago and decided I'd just treat disks as consumables, and buy more as-and-when. |
#4
| |||
| |||
|
|
On Jul 14, 2009, at 11:51 AM, Roy Hann wrote: Scott wrote: Hello Folks, * *Does anyone have anaccurateway to calculate the amount of disk spaces needed for tables ? ... I don't think you are ever going to get a veryaccuratecalculation because sometimes the per-row overhead is variable. Chip Nickolett has a spreadsheet at http://www.comp-soln.com/var_page.xlsthat might be of interest. I spent a fair bit of time fiddling with the calculation a couple of years ago and decided I'd just treat disks as consumables, and buy * more as-and-when. I'm going to steal a jump on Mikey by proclaiming "Disks Are Free". *:-) I understand that the OP is trying to use disk space as a trigger for modifying, but the trick there is to use space change, not an absolute calculation. *Compute a rows per page across the entire table, and maintain that value over time; *when it goes down by "enough" you re-modify the table to reconstruct. *(here I mean a fractional average rows-per-page, not an integral actual rows-per-page.) If the table is largely an OLTP-style table, with relatively few rows looked-up per query, space used is pretty much irrelevant since Disks Are Free. *If queries often or even sometimes scan large chunks of the table, sequential disk layout becomes relevant, and effective modification is more a function of filesystem layout policy than space usage. *(e.g. for partitioned tables, set the degree_of_parallelism config setting to 1, so that modifies are non-parallelized and result in more sequential allocations. *Or, set filesystem reservation policies to generously large amounts. *Whatever it takes.) Karl- Hide quoted text - - Show quoted text - |
#5
| |||
| |||
|
|
On Jul 14, 2009, at 11:51 AM, Roy Hann wrote: Scott wrote: Hello Folks, * *Does anyone have anaccurateway to calculate the amount of disk spaces needed for tables ? ... I don't think you are ever going to get a veryaccuratecalculation because sometimes the per-row overhead is variable. Chip Nickolett has a spreadsheet at http://www.comp-soln.com/var_page.xlsthat might be of interest. I spent a fair bit of time fiddling with the calculation a couple of years ago and decided I'd just treat disks as consumables, and buy * more as-and-when. I'm going to steal a jump on Mikey by proclaiming "Disks Are Free". *:-) I understand that the OP is trying to use disk space as a trigger for modifying, but the trick there is to use space change, not an absolute calculation. *Compute a rows per page across the entire table, and maintain that value over time; *when it goes down by "enough" you re-modify the table to reconstruct. *(here I mean a fractional average rows-per-page, not an integral actual rows-per-page.) If the table is largely an OLTP-style table, with relatively few rows looked-up per query, space used is pretty much irrelevant since Disks Are Free. *If queries often or even sometimes scan large chunks of the table, sequential disk layout becomes relevant, and effective modification is more a function of filesystem layout policy than space usage. *(e.g. for partitioned tables, set the degree_of_parallelism config setting to 1, so that modifies are non-parallelized and result in more sequential allocations. *Or, set filesystem reservation policies to generously large amounts. *Whatever it takes.) Karl- Hide quoted text - - Show quoted text - |
![]() |
| Thread Tools | |
| Display Modes | |
| |