fix(docs): explain label ID

README.md

@@ -14,9 +14,7 @@ compatible with Aurora PostgreSQL, Azure Database for PostgreSQL, and other mana
 This adapter uses a schema that is compatible with [the Timescale `pg_prometheus` adapter](https://github.com/timescale/prometheus-postgresql-adapter/) but does not require the `pg_prometheus` extension or `SUPERUSER`/plugin permissions.
 
 With v0.2, the metric labels and samples are separated into two data tables and a joining view, linked by a label ID
-(`lid`). The `lid` is generated by calling the Prometheus metric's `String()` method, then taking the base64-encoded
-SHA-1 hash of the results. This provides a short, deterministic identifier for each unique set of labels at the cost
-of some CPU (less than `100m` per 1k samples/sec on an old Xeon E3-1245v2).
+(`lid`).
 
 The resulting schema can be `\d`escribed as:
 
@@ -62,3 +60,15 @@ View definition:
    FROM metric_samples s
      JOIN metric_labels l ON s.lid = l.lid;
 ```
+
+### Label ID
+
+Where [the original schema](https://github.com/timescale/prometheus-postgresql-adapter/blob/master/pkg/postgresql/client.go#L72)
+uses a temporary table and `INSERT INTO %s_labels (metric_name, labels)`, this schema links the samples with their
+labels using a hashed label ID. The `lid` is generated by calling the Prometheus metric's `String()` method, then
+taking the base64-encoded SHA-1 hash of the results. This provides a short, deterministic identifier for each unique
+set of labels at the cost of some CPU (less than `100m` per 1k samples/sec on an old Xeon E3-1245v2).
+
+The metric string hashed to produce `lid` includes the metric name - twice, as the string prefix and `__name__`
+label - and provides a constant-length key to be indexed and easily skipped with `ON CONFLICT DO NOTHING`. The `lid`
+also provides a natural order and segment key for later chunk reordering and compression.