Add a delta-maintained summary table tag-cloud strategy

[igor-alexandrov]

Summary

Adds a third tag-cloud generator strategy, metka:strategies:table, alongside view and materialized_view: a real summary table (tag_name primary key, taggings_count bigint NOT NULL) kept exact by statement-level triggers that apply per-tag deltas from transition tables.

Motivation

Benchmarks (10k posts, 5 tags each, 100-tag vocabulary, PostgreSQL 18) showed the materialized_view strategy's statement-level REFRESH MATERIALIZED VIEW CONCURRENTLY costs ~7 ms per tagged write statement at that size — creates 12x and tag-list updates 47x slower than an unmaintained table, with cost growing with table size since every refresh is a full recompute. Delta upserts from transition tables instead keep writes within benchmark noise of an unmaintained table (creates 1,484 vs 1,633 i/s; updates 7,879 vs 8,248 i/s), stay transactional and exact, and read faster than the matview.

Implementation

• Generator modeled on materialized_view (same options, with --table-name in place of --view-name); migration seeds the table via INSERT .. SELECT UNNEST .. GROUP BY from existing rows.
• One function + one FOR EACH STATEMENT trigger per operation, since a transition table is only registered for its own trigger:
  • INSERT: aggregate new_rows, upsert with ON CONFLICT .. DO UPDATE adding the delta.
  • UPDATE: signed UNION ALL over new_rows/old_rows, HAVING SUM(d) <> 0 to skip untouched tags, upsert, then delete rows at <= 0.
  • DELETE: subtract aggregated old_rows counts, then delete rows at <= 0.
• Verified live against PostgreSQL 18: UNNEST of a NULL array yields no rows and array concatenation treats a NULL operand as empty (array_cat is not strict), so no explicit NULL guards are needed; a mixed workload (multi-row statements, NULL/empty arrays, no-op updates, duplicate tags within a row) leaves the table exactly matching a live UNNEST .. GROUP BY aggregation — the model test asserts this at the end.
• README documents the trade-off: same read shape as the views, near-zero write overhead, O(tags touched) maintenance; but it is a plain table, so writes that bypass the triggers (TRUNCATE, dump restore) require a manual reseed — same ownership caveat as raw column writes.

Testing

• bundle exec rake test: 158 runs, 433 assertions, 0 failures (PostgreSQL 18.3).
• RuboCop and mdl clean.

🤖 Generated with Claude Code

[igor-alexandrov]

Rebased on master to pick up the benchmark suite from #85, and extended it to cover the tag-cloud strategies: the cloud/write suites now include Metka variants maintained by the materialized_view and table strategies (DDL matching the generators' output), and every run ends with an integrity check of both aggregates against a live UNNEST .. GROUP BY aggregation.

Fresh numbers (10k posts, PostgreSQL 18.3), bare / materialized_view / table:

Operation	bare	materialized_view	table
Tag cloud read	209 i/s	9,082 i/s	9,337 i/s
Create post with 5 tags	1,631 i/s	133 i/s	1,524 i/s
Replace tags	8,122 i/s	173 i/s	7,696 i/s
Bulk seed 10k posts	0.21 s	0.24 s	0.17 s
Storage	2.68 MB	2.78 MB	2.75 MB

Integrity check after all suites: 0 mismatching tags for both strategies.