GjatĂ« gjashtĂ« muajve tĂ« fundit â shĂ«rbimi publik pĂ«r PostgreSQL.
GjatĂ« muajve tĂ« kaluar kemi bĂ«rĂ« njĂ« raport pĂ«r tĂ« , pĂ«rgatitĂ«m njĂ« tĂ« bazuar nĂ« rekomandimet qĂ« ai jep⊠por mĂ« e rĂ«ndĂ«sishmja â mbledhĂ«m reagimet tuaja dhe ndoqĂ«m rastet reale tĂ« pĂ«rdorimit.
Dhe tani jemi të gatshëm të flasim për mundësitë e reja që mund të përdorni.
Mbështetje për formate të ndryshme të planeve
Plani nga logu, së bashku me kërkesën
Direkt nga konsola, përzgjidhim tërë bllokun, duke filluar nga rreshti me Query Text, me të gjithë hapësirat e para:
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Konflikti Zgjidhja: NOTHING
Indexet për Zgjidhjen e Konflikteve: dicquery_20200604_pkey
Tupla të Shtuar: 1
Tupla Konfliktuese: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Rezultati (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
⊠dhe hedhim gjithçka të kopjuar direkt në fushën për planin, asgjë pa u Ndara:
Në përfundim, marrim si bonus për planin e analizuar edhe tabin "kontekst", ku kërkesa jonë paraqitet në gjithë shkëlqimin e saj:
JSON dhe YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"PavarĂ«sisht nĂ«se me thonjĂ«za tĂ« jashtme, siç kopjon pgAdmin, apo pa â hedhin nĂ« tĂ« njĂ«jtĂ«n fushĂ«, rezultati â bukuri:
Vizualizimi i avancuar
Koha e Planifikimit / Koha e Ekzekutimit
Tani është më e dukshme se ku po shpenzohej koha shtesë gjatë ekzekutimit të kërkesës:
I/O Timing
Ndonjëherë na duhet të përballemi me situatën kur në plan duket se burimet janë lexuar-shkruar jo shumë, por koha e ekzekutimit duket të jetë ndonjëherë e madhe.
Këtu duhet të themi: "Ooo, ndoshta në atë moment disku në server ishte shumë i ngarkuar, prandaj po lexohej kaq ngadalë!" Por kjo nuk është shumë e saktë...
Por mund ta përcaktojmë absolutisht saktë. Problemi është se ndër opsionet e konfigurimit të serverit PG është :
Përfshin matjen e kohës së operacioneve të hyrjes/daljes. Ky parametr është i çaktivizuar si fillim, sepse kërkon kërkimin e vazhdueshëm të kohës aktuale nga sistemi operativ, gjë që mund të ngadalësojë ndjeshëm performancën në disa platforma. Për të vlerësuar shpenzimet e matjes së kohës në platformën tuaj, mund të përdorni utilitarin pg_test_timing. Statistikën e hyrjes/daljes mund ta merrni përmes shikimit pg_stat_database, në daljen EXPLAIN (kur përdoret parametri BUFFERS) dhe përmes shikimit pg_stat_statements.
Ky parametr mund të aktivizohet gjithashtu brenda një seance lokale:
SET track_io_timing = TRUE;Tani, pjesa mĂ« e kĂ«ndshme â kemi mĂ«suar tĂ« kuptojmĂ« dhe tĂ« paraqesim kĂ«to tĂ« dhĂ«na duke marrĂ« parasysh tĂ« gjitha transformimet e pemĂ«s sĂ« ekzekutimit:
KĂ«tu mund tĂ« vĂ«rehet se nga 0.790ms tĂ« gjithĂ« kohĂ«s sĂ« ekzekutimit, 0.718ms u mor nga leximi i njĂ« faqeje tĂ« dhĂ«nash, 0.044ms â nga shkarkimi i saj, dhe pĂ«r tĂ« gjithĂ« aktivitetin e mbetur u pĂ«rdorĂ«n vetĂ«m 0.028ms!
E ardhmja me PostgreSQL 13
Mund të njihni një përmbledhje të plotë të noviteteve , dhe ne konkretisht flasim për ndryshimet në planet.
Planifikimi i bufereve
Llogaritja e burimeve të alokuara për planifikuesin është reflektuar po ashtu në një patch tjetër, që nuk i përket pg_stat_statements. EXPLAIN me opsionin BUFFERS do të raportojë numrin e bufereve të përdorura gjatë fazës së planifikimit:
Seq Scan on pg_class (rreshtat aktuale=386 loops=1) Bufere: shared hit=9 read=4 Koha e Planifikimit: 0.782 ms Bufere: shared hit=103 read=11 Koha e Ekzekutimit: 0.219 ms
Sortimi inkremental
NĂ« rastet kur kĂ«rkohet njĂ« renditje sipas shumĂ« çelĂ«save (k1, k2, k3âŠ), planifikuesi tani mund tĂ« shfrytĂ«zojĂ« njohuritĂ« qĂ« tĂ« dhĂ«nat janĂ« tashmĂ« tĂ« renditura sipas disa nga çelĂ«sat e parĂ« (p.sh. k1 dhe k2). NĂ« kĂ«tĂ« rast, nuk Ă«shtĂ« e nevojshme tĂ« ripĂ«rfshihet tĂ« gjithĂ« tĂ« dhĂ«nat, por mund tĂ« ndahen ato nĂ« grupe tĂ« renditura nĂ« mĂ«nyrĂ« sekondere sipas vlerave tĂ« ngjashme k1 dhe k2, dhe tĂ« âpĂ«rfundojĂ«â sipas çelĂ«sit k3.
Në këtë mënyrë, tërë renditja ndahet në disa renditje të vogla. Kjo redukton sasinë e memories së nevojshme, dhe gjithashtu lejon që të dhënat e para të jepen më herët, para se të përfundojë e tërë renditja.
Incremental Sort (rreshtat aktuale=2949857 loops=1) ĂelĂ«si i Renditjes: ticket_no, passenger_id ĂelĂ«si i Pararenditur: ticket_no Grupi tĂ«rĂ«sor tĂ« renditjes: 92184 Metoda e Renditjes: quicksort Memoria: avg=31kB peak=31kB -> Indeks Skano duke pĂ«rdorur tickets_pkey nĂ« tickets (rreshtat aktuale=2949857 loops=1) Koha e Planifikimit: 2.137 ms Koha e Ekzekutimit: 2230.019 ms
Përmirësime të UI/UX
Kapsht, ata janë kudo!
Tani, nĂ« çdo skedĂ« Ă«shtĂ« shtuar mundĂ«sia pĂ«r tĂ« shpejt bĂ«j njĂ« screenshot tĂ« skedĂ«s nĂ« clipboard nĂ« tĂ« gjithĂ« gjerĂ«sinĂ« dhe thellĂ«sinĂ« e skedĂ«s â «sinkronizimi» nĂ« tĂ« djathtĂ«n-lart:
Në fakt, shumica e imazheve për këtë publikim janë marrë pikërisht kështu.
Rekomandimet në nyje
Jo vetëm që janë rritur numri i tyre, por për secilën mund , duke kaluar nëpër lidhjen:
Fshirja nga arkiva
Disa kĂ«rkuan shumĂ« qĂ« tĂ« shtohej mundĂ«sia pĂ«r tĂ« fshirĂ« "pĂ«rfundimisht" edhe planet qĂ« nuk publikohen nĂ« arkiv â ju lutemi, mjafton tĂ« klikoni ikonen pĂ«rkatĂ«se:
Po ashtu, mos haroni se kemi , ku mund të dërgoni sugjerimet dhe vlerësimet tuaja.
Burimi: habr.com
