Setengah tahun yang lalu - publik ke PostgreSQL.
Selama beberapa bulan terakhir kami telah melakukan tentang dia , menyiapkan ringkasan berdasarkan rekomendasi yang diberikannya ... tetapi yang paling penting, kami mengumpulkan umpan balik Anda dan melihat kasus penggunaan nyata.
Dan sekarang kami siap memberi tahu Anda tentang fitur baru yang dapat Anda gunakan.
Dukungan untuk format paket yang berbeda
Rencanakan dari log, bersama dengan permintaan
Langsung dari konsol, kami memilih seluruh blok, mulai dari baris dengan Teks Permintaan, dengan semua spasi awal:
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)
... dan lempar semua yang disalin langsung ke bidang sesuai rencana, tanpa memisahkan apa pun:
Di pintu keluar, kami juga mendapatkan bonus untuk paket yang dibongkar tab konteks, di mana permintaan kami disajikan dengan segala kemuliaan:
JSON dan 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
}
]"Bahkan dengan kutipan eksternal, seperti yang disalin pgAdmin, bahkan tanpa - kami memasukkan bidang yang sama, hasilnya cantik:
Visualisasi Tingkat Lanjut
Waktu Perencanaan / Waktu Pelaksanaan
Sekarang Anda dapat melihat dengan lebih baik ke mana perginya waktu ekstra saat menjalankan kueri:
Waktu I/O
Kadang-kadang Anda harus menghadapi situasi di mana, dalam hal sumber daya, tampaknya tidak terlalu banyak yang dibaca dan ditulis, tetapi tampaknya waktu eksekusi terlalu lama untuk beberapa alasan.
Harus dikatakan di sini:Oh, pada saat itu, disk di server mungkin terlalu sibuk, jadi butuh waktu lama untuk membacanya!"Tapi entah bagaimana itu tidak terlalu akurat ...
Tapi itu bisa ditentukan dengan sangat andal. Faktanya adalah bahwa di antara opsi konfigurasi server PG ada :
Mengaktifkan operasi I/O berwaktu. Pengaturan ini dinonaktifkan secara default, karena memerlukan sistem operasi untuk terus menanyakan waktu saat ini, yang dapat memperlambat banyak hal secara signifikan pada beberapa platform. Anda dapat menggunakan utilitas pg_test_timing untuk memperkirakan overhead waktu pada platform Anda. Statistik I/O dapat diperoleh melalui tampilan pg_stat_database, dalam keluaran EXPLAIN (ketika parameter BUFFERS digunakan) dan melalui tampilan pg_stat_statements.
Opsi ini juga dapat diaktifkan dalam sesi lokal:
SET track_io_timing = TRUE;Nah, sekarang bagian terbaiknya adalah kita telah belajar memahami dan menampilkan data ini, dengan mempertimbangkan semua transformasi pohon eksekusi:
Di sini Anda dapat melihat bahwa dari total waktu eksekusi 0.790 md, 0.718 md membutuhkan waktu membaca satu halaman data, 0.044 md - menulisnya, dan hanya 0.028 md yang dihabiskan untuk semua aktivitas berguna lainnya!
Masa depan dengan PostgreSQL 13
Untuk ikhtisar lengkap tentang apa yang baru, lihat , dan kami secara khusus berbicara tentang perubahan rencana.
Buffer perencanaan
Akuntansi untuk sumber daya yang dialokasikan ke penjadwal tercermin dalam tambalan lain yang tidak terkait dengan pg_stat_statements. JELASKAN dengan opsi BUFFERS akan melaporkan jumlah buffer yang digunakan selama tahap 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
Sortir tambahan
Dalam kasus di mana penyortiran dengan banyak kunci (k1, k2, k3β¦) diperlukan, perencana sekarang dapat memanfaatkan mengetahui bahwa data telah diurutkan oleh beberapa kunci pertama (mis. k1 dan k2). Dalam hal ini, Anda tidak dapat mengurutkan ulang semua data lagi, tetapi membaginya menjadi grup yang berurutan dengan nilai k1 dan k2 yang sama, dan "mengurutkan ulang" dengan kunci k3.
Dengan demikian, seluruh penyortiran dipecah menjadi beberapa penyortiran berturut-turut dengan ukuran yang lebih kecil. Ini mengurangi jumlah memori yang diperlukan, dan juga memungkinkan Anda mengembalikan data pertama sebelum semua penyortiran selesai.
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
Peningkatan UI/UX
Tangkapan layar ada di mana-mana!
Sekarang di setiap tab ada peluang untuk cepat ambil screenshot tab ke clipboard untuk seluruh lebar dan kedalaman tab - "melihat" kanan atas:
Sebenarnya, sebagian besar gambar untuk publikasi ini diperoleh dengan cara ini.
Rekomendasi Node
Tidak hanya ada lebih banyak dari mereka, tetapi tentang masing-masing yang Anda bisa dengan mengikuti tautan:
Menghapus dari arsip
Beberapa telah meminta kemampuan untuk hapus "benar-benar" bahkan rencana yang tidak diterbitkan dalam arsip - silakan klik saja ikon yang sesuai:
Yah, jangan lupa bahwa kita punya di mana Anda dapat menulis komentar dan saran Anda.
Sumber: www.habr.com