Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cold shape requests are slow when PostgreSQL has higher network latency

Aperta
  • Qualcosa non va?
#4,828 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
elixir, postgresql
Ambito
databases, performance

Direzione di ricerca

Start with the display_settings/0 implementation in the referenced Electric module and snapshot_query.ex, where the issue says Postgrex.query! runs each setting separately. Trace the snapshot transaction and compare cold request latency with the reproduction against a higher latency PostgreSQL connection. The suspected cause is unconfirmed; done means establishing whether combining the settings reduces sequential database calls and cold request latency.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

triage

I was testing Electric 1.8.1 and seeing a noticeable difference in cold shape request latency depending on how close Electric is to PostgreSQL. Database is hosted on Neon cloud.

  • Local Electric → PostgreSQL (~60ms DB latency): request takes around 1.5 seconds
  • Electric deployed closer to PostgreSQL (~20 ms DB latency): request takes around 300 ms

Warm requests return in a few milliseconds.

Reproduction

  1. Run Electric against PostgreSQL with noticeable network latency.

  2. Request a new shape with offset=-1 and a previously unused filter value:

    curl -sS -G 'http://localhost:3000/v1/shape'
    --data-urlencode 'table=public.example'
    --data-urlencode 'offset=-1'
    --data-urlencode 'where=run_id = $1'
    --data-urlencode 'params[1]='
    --output /dev/null
    --write-out 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n'

  3. Repeat with different filter values to measure cold requests, then repeat the same requests to compare warm responses.

Suspected cause

The snapshot setup appears to make several sequential database calls, so network latency could account for a significant part of the delay.

Trace for a request that took 1.33s shows that span shape_snapshot.set_display_settings took 595ms, and shape_snapshot.query_fn took 414ms.

In particular, display_settings/0 in postgres.ex (https://github.com/electric-sql/electric/blob/%40core%2Fsync-service%401.8.1/packages/sync-service/lib/electric/postgres.ex) defines five statements:

SET bytea_output = 'hex';
SET DateStyle = 'ISO, DMY';
SET TimeZone = 'UTC';
SET extra_float_digits = 1;
SET IntervalStyle = 'iso_8601';

snapshot_query.ex (https://github.com/electric-sql/electric/blob/%40core%2Fsync-service%401.8.1/packages/sync-service/lib/electric/postgres/snapshot_query.ex) executes these through an Enum.map, calling Postgrex.query! separately for each statement inside the snapshot transaction.

Could these settings be applied in one database call, for example using a single SELECT with multiple set_config calls? I haven't tested that yet, so this is only suspected, not confirmed.

Lingua principale
TypeScript
Stelle
10.4k
Fork
394
Merge medio
22h 11m
PR unite (30g)
5

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di electric-sql/electric

Tutte le issue di electric-sql/electric

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.