Warum sind PostgreSQL-Abfragen in der ersten Anfrage nach der ersten neuen Verbindung langsamer als in den nachfolgenden Anfragen?

Question

Warum sind PostgreSQL-Abfragen in der ersten Anfrage nach der ersten neuen Verbindung langsamer als in den nachfolgenden Anfragen?

Verwenden mehrerer verschiedener Technologien zum Herstellen einer Verbindung zu einer postgresql-Datenbank. Die erste Anfrage kann 1,5 Sekunden dauern. Genau dieselbe Abfrage dauert 0,03 Sekunden beim zweiten Mal. Öffnen Sie eine zweite Instanz meiner Anwendung (Verbindung zu derselben Datenbank) und diese erste Anforderung dauert 1,5 Sekunden und die zweiten 0,03 Sekunden.

Wegen der verschiedenen Technologien, die wir verwenden, verbinden sie sich an verschiedenen Punkten und verwenden verschiedene Verbindungsmethoden, so dass ich wirklich nicht denke, dass es irgendetwas mit Code zu tun hat, den ich geschrieben habe.

Ich denke, dass das Öffnen einer Verbindung "alles" bis zur ersten Anfrage nicht tut, so dass die Anfrage einige Gemeinkosten hat.

Da ich die Datenbank verwendet habe und den Server hoch hielt, ist alles im Speicher, so dass Index und dergleichen kein Problem sein sollte.

Bearbeiten Erklären - erzählt mir über die Abfrage und ehrlich gesagt sieht die Abfrage ziemlich gut (indexiert, etc). Ich glaube wirklich, PostgreSQL hat einen gewissen Overhead bei der ersten Abfrage einer neuen Verbindung.

Ich weiß nicht, wie man das beweisen/widerlegen kann. Wenn ich PG Admin III (pgAdmin Version 1.12.3) verwendet habe, scheinen alle Abfragen schnell zu sein. Irgendwelche der anderen Werkzeuge, die ich die erste Frage habe, ist langsam. Meistens ist es nicht merklich langsamer, und wenn es so war, schrieb ich es immer darauf, den RAM mit dem Index zu aktualisieren. Aber das ist eindeutig NICHT das. Wenn ich mein (e) Werkzeug (e) öffne und irgendeine andere Abfrage ausführe, die Ergebnisse liefert, ist die zweite Abfrage unabhängig davon schnell. Wenn die erste Abfrage keine Ergebnisse liefert, ist die zweite noch langsam, dann ist die dritte schnell.

bearbeiten 2 Obwohl ich nicht glaube, die Abfrage nichts mit der Verzögerung zu tun hat (jede erste Abfrage ist langsam) hier sind zwei Ergebnisse aus Erklären läuft (EXPLAIN ANALYZE)

EXPLAIN ANALYZE 
select * from company 
where company_id = 39 

Ausgang:

"Seq Scan on company (cost=0.00..1.26 rows=1 width=54) (actual time=0.037..0.039 rows=1 loops=1)" 
" Filter: (company_id = 39)" 
"Total runtime: 0.085 ms" 

und:

EXPLAIN ANALYZE 
select * from group_devices 
where device_name ilike 'html5_demo' 
and group_id in (select group_id from manager_groups 
where company_id in (select company_id from company where company_name ='TRUTHPT')) 

Ausgabe:

"Nested Loop Semi Join (cost=1.26..45.12 rows=1 width=115) (actual time=1.947..2.457 rows=1 loops=1)" 
" Join Filter: (group_devices.group_id = manager_groups.group_id)" 
" -> Seq Scan on group_devices (cost=0.00..38.00 rows=1 width=115) (actual time=0.261..0.768 rows=1 loops=1)" 
"  Filter: ((device_name)::text ~~* 'html5_demo'::text)" 
" -> Hash Semi Join (cost=1.26..7.09 rows=9 width=4) (actual time=0.297..1.596 rows=46 loops=1)" 
"  Hash Cond: (manager_groups.company_id = company.company_id)" 
"  -> Seq Scan on manager_groups (cost=0.00..5.53 rows=509 width=8) (actual time=0.003..0.676 rows=469 loops=1)" 
"  -> Hash (cost=1.26..1.26 rows=1 width=4) (actual time=0.035..0.035 rows=1 loops=1)" 
"    Buckets: 1024 Batches: 1 Memory Usage: 1kB" 
"    -> Seq Scan on company (cost=0.00..1.26 rows=1 width=4) (actual time=0.025..0.027 rows=1 loops=1)" 
"     Filter: ((company_name)::text = 'TRUTHPT'::text)" 
"Total runtime: 2.566 ms" 

Answer 1

Erste-Anforderungs-Blöcke von der Festplatte Puffer lesen. Zweite Anforderung liest aus Puffern.

Es ist egal, wie viele Verbindungen hergestellt werden, ist das Ergebnis davon ab, ob die Abfrage analysiert bereits wurde.

Bitte beachten Sie, dass das Ändern von Literalen die Abfrage analysieren wird. Beachten Sie auch, dass, wenn die Abfrage nicht innerhalb einer bestimmten Zeit ausgeführt wurde, physische Lesevorgänge immer noch abhängig von vielen Variablen auftreten können.