extents size

hi, Knowing the size of a row and the number of rows, is there a method to appreciate the true value of the extents' size of a table ? thank's

Its roughly row size by number of rows. But don´t forget to add up the number of rows the table will grow. If that is a low number, you are done. If its a high number add up a a value that will be good for you in a timely manner and think of the space needs after that first extend is going to be filled up. The hard part on calculating extends is always predicting the future needs.. regards Jörg Volz ----- Ursprüngliche Nachricht ----- Von: JACQUES ALFONSEA <jalfonsea@numericable.fr> Gesendet: Freitag, 30. Dezember 2011 11:30 An: ids@iiug.org <ids@iiug.org> Betreff: extents size [25778] hi, Knowing the size of a row and the number of rows, is there a method to appreciate the true value of the extents' size of a table ? thank's ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum. IT Handel und Beratung Jörg Volz Bernhard-Früh-Str. 7 77855 Achern GERMANY Tel: +49 (0)7841-681651 Fax: +49 (0)7841-681654 Mobil: +49 (0)170-2989757 VAT-ID: DE201383541 http://www.it-volz.de

The rule of thumb I use for extent sizing is that the goal is to always access only one or two extents in any common query (obviously ignore any 'all of history' type queries when figuring this out). So, look at the common queries that will be run against the table and determine what the most frequent working set of data is. If it is a year then an extent should hold a year's worth of data. If you commonly only access a week's worth of data then a week is the minimum extent size. When you consider this you are not only looking at individual queries but at the totality of what all users will be doing concurrently. From there, you figure out how many rows fit on a page, calculate how many pages the common working set will require, and voila! Now if the working set is very small, then you have the luxury to make your extents hold many working sets, but unless the common working set is massive, make sure that the extent and next sizes are at least the size of a single working set so that over a transition period, like the end of a month, that there are only two extents that are active. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Fri, Dec 30, 2011 at 5:26 AM, JACQUES ALFONSEA <jalfonsea@numericable.fr>wrote: > hi, > > Knowing the size of a row and the number of rows, is there a method to > appreciate the true value of the extents' size of a table ? > > thank's > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340e0bbbf96104b54d2d63

Pagesize - 28 (overhead) =3D page available for data =3D PAGEUSE Rowsize + 4 =3D space taken by row. Max of 255 rows per page. So the formula for how many rows you can fit per page is: MIN(255,TRUNC(PAGEUSE/(ROWSIZE+4))) I you want to get more precise, you might want to allow for the table = header page and the bitmap pages that come every PAGEUSE pages, starting = at page 2. Of course with the use of varchars, it becomes different and more (or = less) interesting, one might even say moot. j. On Dec 30, 2011, at 5:26 AM, JACQUES ALFONSEA wrote: > hi,=20 >=20 > Knowing the size of a row and the number of rows, is there a method to=20= > appreciate the true value of the extents' size of a table ?=20 >=20 > thank's=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20

Ah, I see I have the new 3D mailer. You have to read it with special = glasses. Ignore the 3D, it is introduced by the mailer as are the "=3D" signs at = the end of=20 long lines. j. On Dec 30, 2011, at 6:26 AM, Jack Parker wrote: > Pagesize - 28 (overhead) =3D3D page available for data =3D3D PAGEUSE=20= >=20 > Rowsize + 4 =3D3D space taken by row.=20 >=20 > Max of 255 rows per page.=20 >=20 > So the formula for how many rows you can fit per page is:=20 >=20 > MIN(255,TRUNC(PAGEUSE/(ROWSIZE+4)))=20 >=20 > I you want to get more precise, you might want to allow for the table = =3D=20 > header page and the bitmap pages that come every PAGEUSE pages, = starting =3D=20 > at page 2.=20 >=20 > Of course with the use of varchars, it becomes different and more (or = =3D=20 > less) interesting, one might even say moot.=20 >=20 > j.=20 >=20 > On Dec 30, 2011, at 5:26 AM, JACQUES ALFONSEA wrote:=20 >=20 >> hi,=3D20=20 >> =3D20=20 >> Knowing the size of a row and the number of rows, is there a method = to=3D20=3D=20 >=20 >> appreciate the true value of the extents' size of a table ?=3D20=20 >> =3D20=20 >> thank's=3D20=20 >> =3D20=20 >> =3D20=20 >> =3D=20 > = **************************************************************************= =3D=20 > *****=3D20=20 >> Forum Note: Use "Reply" to post a response in the discussion = forum.=3D20=3D=20 >=20 >> =3D20=20 >=20 >=20 > = **************************************************************************= *****=20 > Forum Note: Use "Reply" to post a response in the discussion forum.=20= >=20