Optimize Settled Payment Query for January 2026

HardSQL · PostgreSQL

Problem

Review this SQL query and table definition for Mercury and tell me what performance issues, security vulnerabilities, or anti-patterns you see.

Assess the query structure, parameter handling, indexing needs, authorization boundaries, and maintainability. Provide a corrected executable query using representative constant values rather than driver placeholders.

Output

Return one row per settled payment for account 101 during January 2026.
Include account_id, account_name, payment_id, amount, currency, and created_at.
Order by created_at descending, then payment_id descending.

Output details

Filter rows where status equals settled.
Use an inclusive lower bound of 2026-01-01 00:00:00+00 and an exclusive upper bound of 2026-02-01 00:00:00+00 for created_at.

Schema

mercury_accounts

Column	Type	Description
account_idPK	INTEGER	Unique Mercury account identifier
account_name	VARCHAR(120)	Display name for the account

mercury_payments

Column	Type	Description
payment_idPK	BIGINT	Unique payment identifier
account_id	INTEGER	Account receiving or sending the payment
amount	NUMERIC(14,2)	Payment amount in the stated currency
currency	VARCHAR(3)	ISO currency code
status	VARCHAR(20)	Payment processing status
created_at	TIMESTAMPTZ	Payment creation timestamp

Tablesmercury_accountsmercury_payments

Review this SQL query and table definition for Mercury and tell me what performance issues, security vulnerabilities, or anti-patterns you see.

Output

Return one row per settled payment for account 101 during January 2026.
Include account_id, account_name, payment_id, amount, currency, and created_at.
Order by created_at descending, then payment_id descending.

Output details

Filter rows where status equals settled.
Use an inclusive lower bound of 2026-01-01 00:00:00+00 and an exclusive upper bound of 2026-02-01 00:00:00+00 for created_at.