Olti oy oldin - ommaviy PostgreSQL-ga.
O'tgan oylarda biz u haqida qildik , xulosa tayyorladi u bergan tavsiyalar asosida... lekin eng muhimi, biz sizning fikr-mulohazalaringizni to'pladik va haqiqiy foydalanish holatlarini ko'rib chiqdik.
Va endi biz siz foydalanishingiz mumkin bo'lgan yangi imkoniyatlar haqida gapirishga tayyormiz.
Turli xil reja formatlarini qo'llab-quvvatlash
So'rov bilan birga jurnaldan reja tuzing
To'g'ridan-to'g'ri konsoldan qatordan boshlab butun blokni tanlang So'rov matni, barcha yetakchi boʻshliqlar bilan:
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)
... va ko'chirilgan hamma narsani to'g'ridan-to'g'ri reja maydoniga qo'ying, hech narsani ajratmasdan:
Oxirida biz demontaj qilingan rejaga bonus olamiz va "kontekst" yorlig'i, bu erda bizning iltimosimiz butun ulug'vorligi bilan taqdim etiladi:
JSON va 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
}
]"Yoki tashqi tirnoq bilan, pgAdmin nusxalari sifatida yoki bo'lmasdan - biz uni bir xil maydonga tashlaymiz va natija go'zallikdir:
Kengaytirilgan vizualizatsiya
Rejalashtirish vaqti/bajarish vaqti
Endi so'rovni bajarish uchun qo'shimcha vaqt qayerga sarflanganini yaxshiroq ko'rishingiz mumkin:
I/U Vaqti
Ba'zan siz resurslar nuqtai nazaridan juda ko'p o'qilmagan va yozilmaganga o'xshab ko'rinadigan vaziyatga duch kelishingiz kerak, ammo ijro etish vaqti juda uzoq bo'lib tuyuladi.
Bu erda aytishimiz kerak: "Oh, ehtimol o'sha paytda serverdagi disk haddan tashqari yuklangan edi, shuning uchun uni o'qish juda uzoq davom etdi!"Ammo bu qandaydir to'g'ri emas ...
Ammo bu mutlaqo ishonchli tarzda aniqlanishi mumkin. Gap shundaki, PG serverini sozlash variantlari orasida :
I/U operatsiyalari vaqtini belgilashni yoqadi. Ushbu parametr sukut bo'yicha o'chirilgan, chunki u operatsion tizimni joriy vaqt uchun doimiy ravishda so'rashni talab qiladi, bu esa ba'zi platformalarda ishlashni sezilarli darajada sekinlashtirishi mumkin. Platformangizdagi vaqtni hisoblash uchun siz pg_test_timing yordam dasturidan foydalanishingiz mumkin. I/U statistikasini pg_stat_database ko'rinishi orqali olish mumkin, EXPLAIN chiqishida (BUFFERS parametridan foydalanilganda) va pg_stat_statements ko'rinishi orqali.
Ushbu parametr mahalliy seansda ham yoqilishi mumkin:
SET track_io_timing = TRUE;Xo'sh, endi eng yaxshi tomoni shundaki, biz ijro daraxtining barcha o'zgarishlarini hisobga olgan holda ushbu ma'lumotlarni tushunish va ko'rsatishni o'rgandik:
Bu yerda siz jami bajarish vaqtining 0.790 ms dan 0.718 ms bir ma’lumot sahifasini o‘qishni, 0.044 ms yozishni va boshqa barcha foydali harakatlarga atigi 0.028 ms sarflanganini ko‘rishingiz mumkin!
PostgreSQL 13 bilan kelajak
Innovatsiyalarning to'liq sharhini topishingiz mumkin , va biz, ayniqsa, rejalardagi o'zgarishlar haqida gapiramiz.
Buferlarni rejalashtirish
Rejalashtiruvchiga ajratilgan resurslarni hisobga olish pg_stat_statements bilan bog'liq bo'lmagan boshqa patchda aks ettirilgan. BUFFERS opsiyasi bilan EXPLAIN rejalashtirish bosqichida foydalanilgan buferlar soni haqida xabar beradi:
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
Incremental saralash
Ko'p tugmalar bo'yicha saralash zarur bo'lgan hollarda (k1, k2, k3...), rejalashtiruvchi endi ma'lumotlar bir nechta birinchi tugmachalarda (masalan, k1 va k2) tartiblanganligi haqidagi bilimdan foydalanishi mumkin. Bunday holda, siz barcha ma'lumotlarni qayta saralay olmaysiz, lekin uni k1 va k2 ning bir xil qiymatlari bilan ketma-ket guruhlarga bo'ling va k3 tugmachasi bilan "qayta tartiblang".
Shunday qilib, butun saralash kichikroq o'lchamdagi bir nechta ketma-ket turlarga bo'linadi. Bu talab qilinadigan xotira hajmini kamaytiradi va shuningdek, butun saralash tugagunga qadar birinchi ma'lumotlarni chiqarishga imkon beradi.
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
UI/UX yaxshilanishi
Skrinshotlar, ular hamma joyda!
Endi har bir yorliqda tezda qilish imkoniyati mavjud buferga yorliqning skrinshotini oling yorliqning butun kengligi va chuqurligi - o'ng tepada "ko'rish":
Aslida, ushbu nashr uchun suratlarning aksariyati shu tarzda olingan.
Tugunlar bo'yicha tavsiyalar
Ular nafaqat ko'paydi, balki har biri haqida ham gapirishingiz mumkin havola orqali:
Arxivdan oʻchirish
Ba'zi odamlar haqiqatan ham variantni qo'shishni so'rashdi "to'liq" o'chirish hatto arxivda e'lon qilinmagan rejalar ham - iltimos, tegishli belgini bosing:
Xo'sh, bizda borligini unutmang , bu yerda fikr va takliflaringizni yozishingiz mumkin.
Manba: www.habr.com
