In the absence of a long wipe and numerous harvests from the claim, the number of records in the database per one cell grows by 5 records (young sowing, mature, ripe, soil, fertile soil) for each harvest.
If we calculate that from a field of 400 cells with 10 harvests, the base will increase 400 * 10 * 5 = 20,000 records.
And this is only one claim.
I have a 1.2Gb database on my server
select count (*) from geo_patch = 17862086;
select count (*) from geo_patch where (substance> 100) = 1322917;
Field substances begin with id = 101;
1322917 * 5/3 = 2204861 - extra harvest records.

The suggestion is to delete these entries except for the latest version on the field, since the field height does not actually change. If the field was buried after harvest, then the actual field does not change either.

Hi,
yes I debated about a geo_patch consolidation script some time ago for the reasons you mentioned.
However, any deletion of geo_patch records makes it necessary to go through the whole custom map setup process again. Like after map installation or map refresh.
Also, it doesn't make much sense to minify the geo_patch table because the server never reads from that table except on startup. So minifying that table will maybe speed up the server boot for a couple of seconds but won't have any performance impact during runtime. So the cost-benefit equation isn't good tbh