Sistem multi-agent kolaboratif menghasilkan jejak eksekusi yang masif dalam waktu singkat. Setiap siklus thought, evaluasi tool call, dan respons pesan ke pengguna disimpan ke dalam tabel audit log. Masalah performa muncul ketika sistem monitoring dashboard atau antarmuka web memuat jejak interaksi tersebut menggunakan paging konvensional (OFFSET dan LIMIT).

Bottleneck OFFSET/LIMIT pada Log Multi-Agent

Ketika volume data mencapai jutaan baris, pendekatan OFFSET N LIMIT M memaksa database membaca dan membuang N baris sebelum mengambil M baris yang diinginkan. Kompleksitas waktunya adalah O(N). Operasi ini membebani buffer cache dan disk I/O.

Keyset pagination (cursor-based pagination) mengatasi masalah ini dengan memanfaatkan nilai kolom terindeks dari baris terakhir yang dibaca sebagai penanda (anchor). Query melompat langsung ke target menggunakan perbandingan indeks dengan kompleksitas O(log N).

Skema Database dan Indeks Komposit

Berikut skema tabel untuk mencatat riwayat eksekusi agen dengan indeks yang dioptimalkan untuk traversal sekuensial berdasarkan waktu dan ID.

CREATE TABLE agent_execution_logs (
    id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    agent_id UUID NOT NULL,
    session_id UUID NOT NULL,
    step_type VARCHAR(50) NOT NULL,
    payload JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT CLOCK_TIMESTAMP()
);

-- Indeks komposit mendukung filter agent_id dan pengurutan kronologis terbalik
CREATE INDEX idx_agent_logs_keyset 
ON agent_execution_logs (agent_id, created_at DESC, id DESC);

Kolom id ditambahkan pada indeks untuk memecah nilai created_at yang identik (tie-breaker), menjaga determinisme pagination tanpa kehilangan atau menduplikasi baris.

Implementasi Query: Keyset Pagination vs OFFSET

1. Pendekatan OFFSET Lambat

Query konvensional untuk halaman ke-1000 dengan ukuran batch 20:

SELECT id, agent_id, step_type, created_at
FROM agent_execution_logs
WHERE agent_id = 'a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d'
ORDER BY created_at DESC, id DESC
LIMIT 20 OFFSET 20000;

2. Pendekatan Keyset (Tuple Comparison)

Menggunakan nilai created_at dan id dari item terakhir pada halaman sebelumnya sebagai cursor:

SELECT id, agent_id, step_type, created_at
FROM agent_execution_logs
WHERE agent_id = 'a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d'
  AND (created_at, id) < ('2026-03-30 08:15:23.123456+00', 529401)
ORDER BY created_at DESC, id DESC
LIMIT 20;

Postgres menggunakan Row Constructor Comparison untuk memetakan kondisi (created_at, id) < (...) secara langsung ke struktur B-Tree indeks.

Analisis EXPLAIN ANALYZE

Pengujian dilakukan pada tabel simulasi berisi 5.000.000 baris log.

Eksekusi OFFSET 20000

Limit  (cost=1254.32..1255.57 rows=20 width=64) (actual time=18.412..18.428 rows=20 loops=1)
  ->  Index Scan using idx_agent_logs_keyset on agent_execution_logs  (cost=0.43..31350.21 rows=500000 width=64) (actual time=0.045..16.890 rows=20020 loops=1)
        Index Cond: (agent_id = 'a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d'::uuid)
Planning Time: 0.120 ms
Execution Time: 18.460 ms

Database memindai 20.020 baris indeks hanya untuk mengembalikan 20 baris.

Eksekusi Keyset Pagination

Limit  (cost=0.43..2.11 rows=20 width=64) (actual time=0.038..0.051 rows=20 loops=1)
  ->  Index Scan using idx_agent_logs_keyset on agent_execution_logs  (cost=0.43..31350.21 rows=500000 width=64) (actual time=0.036..0.047 rows=20 loops=1)
        Index Cond: ((agent_id = 'a1b2c3d4-e5f6-7a8b-9c0d-1e2f3a4b5c6d'::uuid) AND ((created_at, id) < ('2026-03-30 08:15:23.123456+00'::timestamptz, 529401)))
Planning Time: 0.115 ms
Execution Time: 0.075 ms

Query langsung menuju simpul indeks yang ditargetkan tanpa membaca baris terdahulu, memangkas waktu eksekusi dari 18.46 ms menjadi 0.075 ms.

Trade-off dan Limitasi

  • Tidak Ada Navigasi Bebas: Keyset pagination tidak mendukung lompatan acak ke halaman tertentu (misalnya langsung ke halaman 50). Sistem hanya mendukung alur next dan previous.
  • Konsistensi Data: Jika data log di-insert secara real-time, keyset pagination stabil terhadap pergeseran baris. Tidak ada risiko entri terlewat atau terduplikasi akibat penambahan baris baru di awal tabel.
  • Kebutuhan Index B-Tree: Seluruh kolom pembanding urutan harus terdefinisi ketat dan konsisten dengan arah pengurutan indeks (DESC/ASC).