[checkpoint-postgres] Greenplum list query very slow — CTE-based savers & PR to main?

OSS Product Help LangGraph
1

Hi,

We’re using LangGraph with checkpoint-postgres on Greenplum. The existing PostgresSaver / AsyncPostgresSaver work, but listing checkpoints (list() / alist()) is extremely slow. The default SQL uses correlated subqueries; on Greenplum’s MPP engine that leads to broadcasting the full inner tables to every segment, so cost is O(full_table × num_segments). In our setup (5000+ threads, 100K+ rows per table), even list(..., limit=10) can take ~10 seconds.

I’ve implemented optional Greenplum-oriented savers that keep the same API but use a CTE + JOIN list query instead. The planner then uses Redistribute Motion (only matching rows move), and the same limit=10 call drops to ~100ms. The change is additive: a new greenplum.py module with AsyncGreenplumSaver / GreenplumSaver, plus a small refactor in base.py so subclasses can override _build_list_query(). Default Postgres behavior is unchanged; no new dependencies; existing tests are extended to cover the Greenplum savers.

Two things I’d like your input on:

  1. Wording / scope
    Is there anything you’d rephrase or clarify (e.g. “for Greenplum and similar MPP only”, or how to describe the optimization) before sharing this more widely or opening a PR?

  2. Where this should live
    Do you think this belongs as a PR to the main langgraph repo (as an optional backend in checkpoint-postgres), or would you prefer it as a separate package (e.g. langgraph-checkpoint-greenplum) or a documented workaround (subclass + override) in the docs? I’m happy to go either way and can adapt the implementation accordingly.

Thanks in advance.

2

You could make a separate repo ! similar to the redis or mongodb ones