Skip to content

Run PRAGMA optimize after commiting ingestion to the database #579

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Shaptic wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Run PRAGMA optimize after commiting ingestion to the database #579

Show file tree
Hide file tree
Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
faa3d51
Run sqlite optimization after ingestion db connection closes:
Shaptic Dec 23, 2025
bc02021
Remove unused ledger entry cache (Core does it now)
Shaptic Dec 23, 2025
2730b18
Merge branch 'main' into optimize-on-close
Shaptic Dec 23, 2025
cd5c8b5
Merge branch 'main' into optimize-on-close
Shaptic Jan 15, 2026
95a8304
Track metrics on db optimization
Shaptic Feb 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 5 additions & 10 deletions cmd/stellar-rpc/internal/db/db.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,6 @@ type WriteTx interface {
type dbCache struct {
latestLedgerSeq uint32
latestLedgerCloseTime int64
ledgerEntries transactionalCache // Just like the DB: compress-encoded ledger key -> ledger entry XDR
sync.RWMutex
}

Expand All @@ -60,8 +59,8 @@ type DB struct {

func openSQLiteDB(dbFilePath string) (*db.Session, error) {
// 1. Use Write-Ahead Logging (WAL).
// 2. Disable WAL auto-checkpointing (we will do the checkpointing ourselves with wal_checkpoint pragmas
// after every write transaction).
// 2. Disable WAL auto-checkpointing (we will do the checkpointing ourselves
// with wal_checkpoint pragmas after every write transaction).
// 3. Use synchronous=NORMAL, which is faster and still safe in WAL mode.
session, err := db.Open("sqlite3",
fmt.Sprintf("file:%s?_journal_mode=WAL&_wal_autocheckpoint=0&_synchronous=NORMAL", dbFilePath))
Expand All @@ -85,9 +84,7 @@ func OpenSQLiteDBWithPrometheusMetrics(dbFilePath string, namespace string, sub
}
result := DB{
SessionInterface: db.RegisterMetrics(session, namespace, sub, registry),
cache: &dbCache{
ledgerEntries: newTransactionalCache(),
},
cache: &dbCache{},
}
return &result, nil
}
Expand All @@ -99,9 +96,7 @@ func OpenSQLiteDB(dbFilePath string) (*DB, error) {
}
result := DB{
SessionInterface: session,
cache: &dbCache{
ledgerEntries: newTransactionalCache(),
},
cache: &dbCache{},
}
return &result, nil
}
Expand Down Expand Up @@ -241,7 +236,7 @@ func (rw *readWriter) NewTx(ctx context.Context) (WriteTx, error) {
postCommit: func(durationMetrics map[string]time.Duration) error {
// TODO: this is sqlite-only, it shouldn't be here
startTime := time.Now()
_, err := db.ExecRaw(ctx, "PRAGMA wal_checkpoint(TRUNCATE)")
_, err := db.ExecRaw(ctx, "PRAGMA wal_checkpoint(TRUNCATE); PRAGMA optimize;")
Copy link
Contributor

@sreuland sreuland Jan 15, 2026

Choose a reason for hiding this comment

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

It is unclear what the upper bound on this PRAGMA is: obviously if it exceeds ledger close time this is hugely problematic. The alternative is to ask DB operators to run ANALYZE events regularly which seems silly.

agreed, this seems may be potential for transient delays during ingestion given the single threaded ingestion loop will block until this returns. It also introduces a lock on event table that could pause json-rpc getEvents requests at same time?

this usage does leverage the lightweight analyze behavior per analyze_limit docs as long as the sqlite version is >= 3.46.0

two things for consideration:

  • move this to an async timer loop? Like once every expected ledger close time+1s or something. That ensures an analyze is run close to the ledger ingestion period but avoids impacting the sync ingestion routine, could still introduce some occasional blocking on rpc query requests to events table.
  • run optimize in a follow-on ExecRaw statement? wrap some logging output around that and new metrics key for duration of optimize to get breakout visibility.

Copy link
Contributor Author

@Shaptic Shaptic Jan 24, 2026

Choose a reason for hiding this comment

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

This affects all of ingestion (post-commit for the whole ledger), not just events, so the impact is even bigger if it will interfere with reads.

Yeah your second point is ideal. Before mucking with a timed analyze call, I’m gonna isolate this and run it in the dev cluster to get timing metrics around how long the runs take. If they’re not concerning at all (ms), I won’t bother with strict timing bounds.

if err != nil {
return err
}
Expand Down
2 changes: 1 addition & 1 deletion cmd/stellar-rpc/internal/ingest/service.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -219,7 +219,7 @@ func (s *Service) ingest(ctx context.Context, sequence uint32) error {

s.logger.
WithField("duration", time.Since(startTime).Seconds()).
Debugf("Ingested ledger %d", sequence)
Infof("Ingested ledger %d", sequence)

s.metrics.ingestionDurationMetric.
With(prometheus.Labels{"type": "total"}).
Expand Down
Loading