Hi @heurteph-ei , thanks for your answer. I don’t understand “segmentation” really in the case of database.
The Plugin DBStats (Core) is inactive. I had used phpMyAdmin.
Yes, the segmentation definitions are stored in the database table segment.
- Rows: 12
- Size: 16.0 KiB
Current, all segmentations are “deleted” (database table entry).
deletedtinyint(4) NOT NULL DEFAULT 0,
deleted = 1
The question about this is, why are the deleted segmentations are furthermore stored in the database? There is no option in the backend to reactivate it. OK, it’s not so relevant, because 16 KiB.
Same question about the database table archive_invalidations.
- Rows: ~165.020
- Size: 20,1 MiB
Why are this data furthermore stored in the database? It’s a little bit relevant with 20 MiB.
as my understanding is that “All visits” is a kind of segment (with no segmentation rule)
It’s a nice thinking. So, with this, segmentations are not separated reports, and segmentations used the same “common” reports, and a segmentation are only filtered the common reports “on-the-fly” by delivery/displaying. The question is yet: Is this true?
If no segment is present in the table, the data archiving should just run on the “All visits” segment…
This is the oposite of the thinking before. So, the “data archiving” stored separate segmentation reports in the database, if a segmentation is present/active?
Are you sure the segmented report is the thing that makes your DB too high?
I’m not sure. I only observed that to date in my database the old archive_* database tables (2021-11 - today) are increased in counterpart of a database dump 1 month behind.
Detailed infos here: Database old archive data strong increased
I don’t know whether saving a segmentation (i.e. not just “test”, but “save”) is to blame for this. For this question is the linked topic.
This question here is reduced to: Why are the “deleted” segmentations and the past invalidations are furthermore stored in the database table segment and archive_invalidations?