Disk usage don't include synthetic _id postings (elastic#138745)

* Disk usage don't include synthetic _id postings

* Update docs/changelog/138745.yaml

* Assert expected _id field in short circuit

Author: burqen

docs/changelog/138745.yaml

@@ -0,0 +1,5 @@
+pr: 138745
+summary: Disk usage don't include synthetic `_id` postings
+area: Distributed
+type: enhancement
+issues: []

server/src/main/java/org/elasticsearch/action/admin/indices/diskusage/IndexDiskUsageAnalyzer.java

@@ -56,6 +56,7 @@
 import org.elasticsearch.core.CheckedConsumer;
 import org.elasticsearch.core.IOUtils;
 import org.elasticsearch.index.codec.postings.ES812PostingsFormat;
+import org.elasticsearch.index.mapper.SyntheticIdField;
 import org.elasticsearch.index.shard.ShardId;
 import org.elasticsearch.index.store.LuceneFilesExtensions;
 
@@ -368,6 +369,12 @@ void analyzeInvertedIndex(SegmentReader reader, IndexDiskUsageStats stats) throw
             if (terms == null) {
                 continue;
             }
+            if (SyntheticIdField.hasSyntheticIdAttributes(field.attributes())) {
+                // Synthetic _id field doesn't have an inverted index stored on disk,
+                // but it pretends to have one on the read path by setting IndexOptions.DOCS
+                assert SyntheticIdField.NAME.equals(field.getName()) : "Expected only synthetic id fields to have synthetic id attribute";
+                continue;
+            }
             // It's expensive to look up every term and visit every document of the postings lists of all terms.
             // As we track the min/max positions of read bytes, we just visit the two ends of a partition containing
             // the data. We might miss some small parts of the data, but it's an good trade-off to speed up the process.