Conversation
Add named prepared statement API: - pgo:prepare/2,3 — parse and cache named statement, returns parameter OIDs - pgo:query_prepared/3,4 — execute prepared statement (skips PARSE) - pgo_prepared_cache — ETS-based statement metadata cache The prepared_query path sends only BIND+DESCRIBE+EXECUTE+SYNC, skipping the PARSE step entirely. This eliminates server-side query parsing and planning on repeated queries. Includes 13 new Common Test cases covering prepare, query_prepared, error handling, rows_as_maps, and with_conn usage.
Taure
force-pushed
the
feat/prepared-statements
branch
from
March 22, 2026 15:25
83a13de to
9f2ff5f
Compare
query_prepared now transparently prepares statements on connections
that haven't seen them yet. On first use of a connection, it calls
pgo_handler:prepare before executing. Subsequent calls on the same
connection skip the prepare step via ETS-based tracking.
- pgo_prepared_cache tracks {ConnectionPid, StatementName} pairs
- maybe_prepare_on_conn/3 handles auto-prepare in pgo:query_prepared
- Handles "already prepared" (42P05) gracefully
- New test: auto_prepare_across_pool with pool_size=5 and 20 queries
Use edoc comments instead of -doc/-moduledoc attributes for OTP 26 compatibility.
tsloughter
requested changes
Sep 9, 2026
| Pool = maps:get(pool, Options, default), | ||
| PoolOptions = maps:get(pool_options, Options, []), | ||
| DecodeOptions = maps:get(decode_opts, Options, []), | ||
| case checkout(Pool, PoolOptions) of |
Collaborator
There was a problem hiding this comment.
Any existing transaction is ignored?
|
|
||
| %% @doc Store a prepared statement's query and parameter OIDs. | ||
| -spec store(iodata(), iodata(), [pg_types:oid()]) -> ok. | ||
| store(Name, Query, OIDs) -> |
Collaborator
There was a problem hiding this comment.
Does this need to be per-pool?
Or maybe the whole cache should be per-pool and started in the supervisor with the pool?
| -define(CONN_TABLE, pgo_prepared_conn_cache). | ||
|
|
||
| %% @doc Initialize cache tables. Safe to call multiple times. | ||
| init() -> |
Collaborator
There was a problem hiding this comment.
Should be a process so it can be supervised and the tables aren't owned by whoever called init?
| end. | ||
|
|
||
| maybe_prepare_on_conn(Owner, NameBin, Conn) -> | ||
| Key = {Owner, NameBin}, |
Collaborator
There was a problem hiding this comment.
Using Owner means that the underlying postgres connection may have reconnected and lost the prepared statement. This needs to be keyed on the actual socket maybe or do a flush when the Owner has to reconnect.
| {ok, Ref={_, _, _, Holder}, Conn=#conn{owner=Owner, decode_opts=DefaultDecodeOpts}} -> | ||
| try | ||
| NameBin = iolist_to_binary(Name), | ||
| _ = maybe_prepare_on_conn(Owner, NameBin, Conn), |
Collaborator
There was a problem hiding this comment.
Won't this mean if preparing fails it'll continue on and ultimately return the wrong error message when it should tell the user why the preparation failed?
|
|
||
| -spec query_prepared(iodata(), list(), [pg_types:oid()], options()) -> result(). | ||
| query_prepared(Name, Params, ParameterOIDs, Options) -> | ||
| pgo_prepared_cache:init(), |
Collaborator
There was a problem hiding this comment.
Why setup caches here like this?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pgo:prepare/2,3— parse a named prepared statement, returns{ok, Name, ParameterOIDs}pgo:query_prepared/3,4— execute a prepared statement by name, skipping PARSE entirelypgo_prepared_cachemodule — ETS-based cache for statement metadataMotivation
pgo currently uses unnamed statements (
"") for every query, forcing PostgreSQL to parse and plan each one. Named prepared statements allow skipping the PARSE step on repeated queries, sending only BIND→DESCRIBE→EXECUTE→SYNC.Benchmarks with erlperf show:
select_one_by_id: +65% throughput (6,500 → 10,700 ops/sec)count(*): +61% (7,300 → 11,800 ops/sec)select 100 rows: +20% (1,500 → 1,800 ops/sec)Usage
Test plan