in place table alter
Posted in 2000
Topics: Performance & Tuning, Migration, Import/Export & Data Conversion
We are using 7.31 and when altering a table, we are adding a new field after the last existing field. We know that an in-place alter will take place and the alter will be quick. The data might not be on the same page (the new fields with the old fields). As date rows are modified, they are then put back on the same page. Will the performance suffer when doing a read before the data is re-formatted on the same page or will it not be affected? As a rule, we have always unloaded the table and re-created it with the new fields so the data would not be fragmented. We are debating whether this is actually necessary in 7.31. Thanks Much. Sent via Deja.com http://www.deja.com/ Before you buy.
With an inplace alter, the added column will receive the default value or null as the row is read. This is a minimal cost. If a page is updated, then all of the rows on that page will be physically converted to the new format. If all of the rows will not fit on the same page, then some of the rows will be updated to a new page. So, the overall cost is not that great. If you are concerned about this, then you can update the newly added column after doing the alter. gresmi@yahoo.com wrote: > We are using 7.31 and when altering a table, we are adding a new field > after the last existing field. We know that an in-place alter will take > place and the alter will be quick. The data might not be on the same > page (the new fields with the old fields). As date rows are modified, > they are then put back on the same page. Will the performance suffer > when doing a read before the data is re-formatted on the same page or > will it not be affected? As a rule, we have always unloaded the table > and re-created it with the new fields so the data would not be > fragmented. We are debating whether this is actually necessary in 7.31. > > Thanks Much. > > Sent via Deja.com http://www.deja.com/ > Before you buy.