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.li...@free.fr>
To: BaseX <basex-talk@mailman.uni-konstanz.de>
Subject: [basex-talk] size on collection in the time
Message-ID: <55e71773.7050...@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
