Verify LISTEN/NOTIFY tick wakeups semantics and performance

[NikolayS]

Context

PgQue's batching model makes events visible to consumers at tick/batch-boundary time, not at individual send() time. A low-latency consumer wakeup mechanism should respect that model.

Question to verify

Should PgQue emit LISTEN/NOTIFY notifications on successful ticks, rather than on each event insert?

Candidate shape:

• producers call send() / send_batch() normally; no per-event NOTIFY
• ticker() creates the tick / batch boundary
• after a successful tick, PgQue emits one notification per queue, e.g. channel pgque_<queue> with payload containing tick_id or compact metadata
• consumers LISTEN, wake up, then call receive()
• correctness must not depend on notification delivery; normal polling remains the fallback

Why this matters

Per-event notifications look wrong for PgQue because they can create notification storms and bypass the core batching assumption. Tick-level notifications should reduce end-to-end latency without changing queue semantics.

Verification needed

• Confirm exact semantics: notify only when a tick actually advances / makes events visible?
• Confirm payload shape: tick_id, queue name, maybe event count?
• Check missed-notification behavior: polling fallback must be sufficient.
• Benchmark overhead under high send rate and high tick rate.
• Compare per-event vs per-tick notification cost to document why per-event is intentionally avoided.
• Check PostgreSQL NOTIFY queue behavior/backpressure under many queues/consumers.

Acceptance criteria

• A small design note documents the chosen semantics.
• A test proves consumers can wake on tick notification and still work if notifications are missed.
• A benchmark or microbenchmark shows notification overhead is acceptable.
• README/roadmap wording says "consumer wakeups on tick", not "notify on send".