Satengah taun katukang - umum kana PostgreSQL.
Dina sababaraha bulan katukang kami parantos nyarios ngeunaan anjeunna , disiapkeun kasimpulan dumasar kana rekomendasi anu dipasihkeun ... tapi anu paling penting, kami ngumpulkeun tanggapan anjeun sareng ningali kasus pamakean anu nyata.
Sareng ayeuna urang siap ngobrol ngeunaan kasempetan anyar anu anjeun tiasa dianggo.
Rojongan pikeun format rencana anu béda
Rencanana tina log, sareng pamundut
Langsung ti konsol nu, pilih sakabeh blok, mimitian ti garis kalawan Téks Patarosan, kalawan sakabeh spasi ngarah:
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)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
... sarta nempatkeun sagalana disalin langsung kana widang rencana, tanpa misahkeun nanaon:
Dina tungtungna urang meunang bonus ka rencana disassembled na tab "konteks"., dimana pamundut urang dibere dina sakabéh kamulyaan na:
JSON sareng 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
}
]"Boh nganggo tanda petik éksternal, sakumaha salinan pgAdmin, atanapi tanpa - urang buang kana widang anu sami, sareng kaluaranna nyaéta kaéndahan:
Visualisasi canggih
Waktos Perencanaan / Waktos Palaksanaan
Ayeuna anjeun tiasa langkung saé ningali dimana waktos tambahan dihabiskeun pikeun ngalaksanakeun pamundut:
I/O Timing
Kadang-kadang anjeun kudu nungkulan kaayaan dimana, dina watesan sumberdaya, sigana nu teu teuing dibaca tur ditulis, tapi waktu palaksanaan sigana incongruously panjang.
Di dieu urang kudu nyebutkeun: "Oh, meureun dina momen éta disk dina server teuing overloaded, éta naha éta nyandak jadi lila maca!"Tapi kumaha waé ieu henteu akurat pisan ...
Tapi ieu bisa ditangtukeun kacida reliably. Kanyataanna nyaéta diantara pilihan konfigurasi server PG aya :
Aktipkeun waktos operasi I/O. Pilihan ieu ditumpurkeun sacara standar sabab merlukeun terus query sistem operasi pikeun waktos ayeuna, nu nyata bisa ngalambatkeun kinerja dina sababaraha platform. Pikeun ngira-ngira biaya waktos dina platform anjeun, anjeun tiasa nganggo utilitas pg_test_timing. Statistik I/O tiasa didapet ngaliwatan pg_stat_database view, dina kaluaran EXPLAIN (nalika parameter BUFFERS dianggo) tur ngaliwatan pintonan pg_stat_statements.
Pilihan ieu ogé tiasa diaktipkeun dina sési lokal:
SET track_io_timing = TRUE;Nya, ayeuna bagian anu pangsaéna nyaéta urang diajar ngartos sareng ningalikeun data ieu kalayan tumut kana sadaya transformasi tangkal palaksanaan:
Di dieu anjeun tiasa ningali yén tina 0.790ms tina total waktos palaksanaan, 0.718ms nyandak hiji halaman data pikeun maca, 0.044ms nyandak nyeratna, sareng ngan ukur 0.028ms anu dianggo pikeun sadaya kagiatan mangpaat anu sanés!
Masa depan sareng PostgreSQL 13
Anjeun tiasa mendakan gambaran lengkep ngeunaan inovasi , sarta kami husus ngobrol ngeunaan parobahan dina rencana.
Perencanaan panyangga
Akuntansi pikeun sumber daya anu dialokasikeun ka scheduler ditingalikeun dina patch sanés anu henteu aya hubunganana sareng pg_stat_statements. NERANGKEUN sareng pilihan BUFFERS bakal ngalaporkeun jumlah panyangga anu dianggo salami fase perencanaan:
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
Asihan Incremental
Dina kasus dimana asihan dina loba kenop diperlukeun (k1, k2, k3 ...), Nu Ngarencana ayeuna bisa ngamangpaatkeun pangaweruh yén data geus diurutkeun dina sababaraha sahiji kenop munggaran (Contona, k1 na k2). Dina hal ieu, anjeun moal bisa deui nyortir sakabéh data, tapi ngabagi kana grup saterusna kalawan nilai sarua k1 jeung k2, sarta "re-sort" ku konci k3.
Ku kituna, sakabéh asihan dibagi kana sababaraha sorts saterusna ukuran leutik. Ieu ngirangan jumlah mémori anu diperyogikeun sareng ogé ngamungkinkeun data anu munggaran kaluaran sateuacan sadayana asihan réngsé.
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
Perbaikan UI / UX
Potret layar, aya dimana-mana!
Ayeuna dina unggal tab aya kasempetan pikeun gancang nyandak screenshot tina tab ka clipboard sakabéh lebar jeung jero tab - "panempoan" dina katuhu-luhur:
Nyatana, seueur gambar pikeun publikasi ieu dicandak ku cara ieu.
Rekomendasi dina titik
Henteu ngan geus aya jadi leuwih ti aranjeunna, Tapi anjeun oge bisa ngobrol ngeunaan unggal ku nuturkeun tautan:
Ngahapus tina arsip
Sababaraha urang bener nanya pikeun nambahkeun pilihan ngahapus "lengkep" bahkan rencana anu henteu diterbitkeun dina arsip - mangga klik ikon anu cocog:
Muhun, ulah poho yén urang boga , dimana anjeun tiasa nyerat koméntar sareng saran anjeun.
sumber: www.habr.com