Topic: AD_ChangeLog_UU - suggested by @giorgio.stefanin
During the conference @giorgio.stefanin suggested me that clearing AD_ChangeLog_UU could have a big impact on database size
he asked me if AD_ChangeLog_UU was important or it can be cleared - and my answer was: "at this moment _UU columns are just used for 2Pack purposes and as AD_ChangeLog is probably not going to be passed between clients using 2Pack you could clear it"
(maybe I'm wrong but AFAIK that's the current status of UUID - we're moving to make more use of that in future - but today that must be the status)
OK - so I took a real-data database and did some tests
these are my findings:
Size of DB
Size of ChangeLog
Just imported
25
13
UPDATE AD_ChangeLog SET AD_ChangeLog_UU = NULL
37
25
VACUUM (INDEX_CLEANUP ON, FULL) AD_ChangeLog
22
10
some interesting facts:
the AD_ChangeLog table was taking 53% of that database
after clearing the UUID it's taking 46% of the DB
the average record size of AD_ChangeLog in this database is 221 bytes, 356 when we add the index space
after clearing the UUID these averages decreased to 183 and 265
so, in average in every record the UUID was taking around 38 bytes of space, and 90 bytes including the indexes
the dmp export also had a decrease of around 8% - so it saves space also in backups
Opening this ticket to implement this suggestion:
to have a flag in AD_Table to say -> for this table don't fill UUID (maybe some implementations can do the same for Fact_Acct or other tables)
this is probably not in line with the goal that we have to move completely to UUID in future - but such decision could be easily reversed, simply run UUID Generator would fill again the column (or a simple UPDATE in SQL)
Bringing from:
https://mattermost.idempiere.org/idempiere/pl/r9pd6jcnkfrkxgd1tu5rz5bs6w
Topic: AD_ChangeLog_UU - suggested by @giorgio.stefanin
During the conference @giorgio.stefanin suggested me that clearing AD_ChangeLog_UU could have a big impact on database size
he asked me if AD_ChangeLog_UU was important or it can be cleared - and my answer was: "at this moment _UU columns are just used for 2Pack purposes and as AD_ChangeLog is probably not going to be passed between clients using 2Pack you could clear it"
(maybe I'm wrong but AFAIK that's the current status of UUID - we're moving to make more use of that in future - but today that must be the status)
OK - so I took a real-data database and did some tests
these are my findings:
Size of DB
Size of ChangeLog
Just imported
25
13
UPDATE AD_ChangeLog SET AD_ChangeLog_UU = NULL
37
25
VACUUM (INDEX_CLEANUP ON, FULL) AD_ChangeLog
22
10
some interesting facts:
the AD_ChangeLog table was taking 53% of that database
after clearing the UUID it's taking 46% of the DB
the average record size of AD_ChangeLog in this database is 221 bytes, 356 when we add the index space
after clearing the UUID these averages decreased to 183 and 265
so, in average in every record the UUID was taking around 38 bytes of space, and 90 bytes including the indexes
the dmp export also had a decrease of around 8% - so it saves space also in backups
Opening this ticket to implement this suggestion:
to have a flag in AD_Table to say -> for this table don't fill UUID (maybe some implementations can do the same for Fact_Acct or other tables)
this is probably not in line with the goal that we have to move completely to UUID in future - but such decision could be easily reversed, simply run UUID Generator would fill again the column (or a simple UPDATE in SQL)