Skip to content

Optimize paginated payment listing queries#240

Closed
joostjager wants to merge 2 commits into
lightningdevkit:mainfrom
joostjager:fix-paginated-list-values
Closed

Optimize paginated payment listing queries#240
joostjager wants to merge 2 commits into
lightningdevkit:mainfrom
joostjager:fix-paginated-list-values

Conversation

@joostjager

Copy link
Copy Markdown
Contributor

This replaces the SQLite pagination index with one that matches the actual paginated store access pattern: namespace filters first, followed by creation_time DESC, key ASC for cursor ordering. The previous creation_time-only index did not fit these queries well and could scan unrelated namespaces or require extra sorting.

It also adds a required list_values paginated store method and implements it in SqliteStore with a single query returning keys and serialized values. ListPayments and ListForwardedPayments now decode those returned values directly, avoiding the previous page-level N+1 pattern where listing 100 items could require 101 SQLite queries.

Use a composite namespace/time/key index because paginated store
queries first constrain primary_namespace and secondary_namespace, then
page and order by creation_time DESC and key ASC. The prior
creation_time-only index did not match that access pattern and could
scan rows from unrelated namespaces or require extra sorting.

Existing databases may retain idx_creation_time; this change only
stops creating it for new databases and creates
idx_paginated_kv_namespace_time_key instead.
Add a required list_values method to the paginated store abstraction
and implement it in SqliteStore with a single query that returns each
page of keys and serialized values. Keep the existing cursor predicate,
ordering, and page-token behavior.

Switch ListPayments and ListForwardedPayments to decode the returned
values directly so each page avoids the per-key read loop.
@ldk-reviews-bot

ldk-reviews-bot commented Jul 3, 2026

Copy link
Copy Markdown

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

@tnull tnull left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're about to drop the SQLite / local forwarded payment store from Server as we're close to finally add all parts to LDK Node. So I don't think it makes sense to make changes to it right now?

@tnull tnull removed the request for review from valentinewallace July 3, 2026 08:29
@joostjager

Copy link
Copy Markdown
Contributor Author

Opened this PR because I still had the code lying around from an older analysis, but I wasn’t fully up to date with what had happened in ldk-node.

The main thing to distill from it is probably this question on ldk-node#959, if it hasn’t already been answered elsewhere: lightningdevkit/ldk-node#959 (comment)

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

@joostjager joostjager closed this Jul 3, 2026
@tnull

tnull commented Jul 3, 2026

Copy link
Copy Markdown
Collaborator

One meta note: the split between ldk-node and ldk-server does make this kind of thing a bit harder to track from the ldk-server side.

Yes, well, that split is exactly what we're trying to reduce currently, i.e., move any remaining custom 'logic' into Node so that Server is really just responsible for the API, dealing with the daemon etc.

@joostjager

Copy link
Copy Markdown
Contributor Author

Once ldk-server is cleaned up again and this stateful logic has moved into ldk-node, I think it would be good to define the boundary strictly so we avoid future work and rework like this.

And I still think keeping this split across two repos introduces unnecessary visibility and change friction, but you all know my stance on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants