Marc,
Are you using the updatable index? UPDINDEX true.
If so, if you look back through the list Christian and I had an exchange on this as I was experiencing an ever growing index - a replace always appended to the end of the index. IIRC the logic is a bit better now in that if on a replace there is enough room in the index structure to reuse slots it will, but if not it will be appended. And the db will reuse empty slots while the database remains open. I can’t remember which is the first version where this change was made, sorry.
I had a DB the other day that had got to 14GB but was only around 600MB once I did a full optimise. My suggestion is next time to try a full optimise instead of dropping the collection and see if that helps.
Regards, James
Message: 1 Date: Wed, 2 Sep 2015 17:36:19 +0200 From: Marc Marc.Liste@free.fr To: BaseX basex-talk@mailman.uni-konstanz.de Subject: [basex-talk] size on collection in the time Message-ID: 55E71773.7050102@free.fr Content-Type: text/plain; charset=iso-8859-15; format=flowed
Hi, I have a remark about the size of the files of a collection. We do a lot of updates (REPLACE) with an attributes index but without a text index. I see that the size of the files grows up in the time we arrive until 30Go until the limit of the filessytems quota. When I drop the collection and recreate it from the last version of the files the size was only 6Go.
We will redo the test with the time, but I just want to know if the program clears the disk use when he does a REPLACE?
Marc
James, We have the UPDINDEX to FALSE. I'll try to do an OPTIMIZE command, but we do it at the end of all the REPLACE so I think that it's not enough. After that I prepare a study case with public data. Regards Marc
Le 03/09/2015 12:17, James Ball a écrit :
Marc,
Are you using the updatable index? UPDINDEX true.
If so, if you look back through the list Christian and I had an exchange on this as I was experiencing an ever growing index - a replace always appended to the end of the index. IIRC the logic is a bit better now in that if on a replace there is enough room in the index structure to reuse slots it will, but if not it will be appended. And the db will reuse empty slots while the database remains open. I can’t remember which is the first version where this change was made, sorry.
I had a DB the other day that had got to 14GB but was only around 600MB once I did a full optimise. My suggestion is next time to try a full optimise instead of dropping the collection and see if that helps.
Regards, James
Message: 1 Date: Wed, 2 Sep 2015 17:36:19 +0200 From: Marc Marc.Liste@free.fr To: BaseX basex-talk@mailman.uni-konstanz.de Subject: [basex-talk] size on collection in the time Message-ID: 55E71773.7050102@free.fr Content-Type: text/plain; charset=iso-8859-15; format=flowed
Hi, I have a remark about the size of the files of a collection. We do a lot of updates (REPLACE) with an attributes index but without a text index. I see that the size of the files grows up in the time we arrive until 30Go until the limit of the filessytems quota. When I drop the collection and recreate it from the last version of the files the size was only 6Go.
We will redo the test with the time, but I just want to know if the program clears the disk use when he does a REPLACE?
Marc
basex-talk@mailman.uni-konstanz.de
-
James Ball -
Marc