The index does get much small when recreated. I think this is some kind of a bug in the recovery code.
Under the normal operation the index file size in our database is about 60% of the data size. However after several power failures it grows to some very unreasonable size (in some cases it is 25 times the data size). We are implementing a work-around that would delete the index file if the size is unreasonable, but I'd much rather have the recovery / store code fixes. Alex On Dec 17, 10:12 pm, trashgod <[email protected]> wrote: > On Dec 16, 5:12 pm, Alex <[email protected]> wrote: > > > > > I have a fairly small database one table has 1400 rows and the other > > table is about 3500 rows. I have 3 primary key indexes and 5 indexes > > on BIGINT column types. > > > The data file size is about 1 MB, however the index size grows to > > about 25+ MB. I don't have the entire diagnostic information yet, but > > I think that it has to do with the power failures and the recovery of > > the index after the failure. > > > The problem is that the larger this index file is the longer it takes > > to recover from the failure next time around. I also looked at the > > index file with the HEX viewer. It appears that beyond the first > > 5%-8% of the file the rest is filled with zeroes. > > > What is the expected data / index size ratio in H2? Is there anything > > short of recreating the index to get it compacted? What can be > > causing most of the index file to have zeroes in it? > > Why not drop and recreate the constraints & indexes? See if it gets > smaller. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/h2-database?hl=en -~----------~----~----~----~------~----~------~--~---
