Жарты жыл бұрын - қоғамдық PostgreSQL үшін.
Соңғы айларда біз ол туралы істедік , түйіндеме дайындады ол берген ұсыныстар негізінде ... бірақ ең бастысы, біз сіздің пікіріңізді жинадық және нақты пайдалану жағдайларын қарастырдық.
Енді біз сізге пайдалануға болатын жаңа мүмкіндіктер туралы айтуға дайынбыз.
Әртүрлі жоспар пішімдерін қолдау
Сұраныспен бірге журналдан жоспар жасаңыз
Консольден тікелей жолдан бастап бүкіл блокты таңдаймыз Сұрау мәтіні, барлық жетекші бос орындармен:
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)
... және ештеңені бөлмей, көшірілгеннің барлығын тікелей жоспар өрісіне тастаңыз:
Шығу кезінде біз бөлшектелген жоспарға бонус аламыз контекст қойындысы, мұнда біздің өтінішіміз барлық салтанатты түрде ұсынылған:
JSON және 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
}
]"Тіпті pgAdmin көшірмелері сияқты сыртқы тырнақшалармен, тіпті онсыз да - біз бір өріске лақтырамыз, нәтиже әдемі:
Кеңейтілген визуализация
Жоспарлау уақыты / Орындау уақыты
Енді сұрауды орындау кезінде қосымша уақыт қайда кеткенін жақсырақ көре аласыз:
Енгізу/шығару уақыты
Кейде сіз ресурстарға қарағанда, тым көп оқылмаған және жазылған сияқты емес сияқты жағдайға тап болуыңыз керек, бірақ қандай да бір себептермен орындау уақыты сәйкес келмейтіндей көрінеді.
Бұл жерде мынаны айту керек:О, бәлкім, сол кезде сервердегі дискіге шамадан тыс жүктелген, сондықтан оқуға көп уақыт кетті!«Бірақ бұл өте дәл емес ...
Бірақ оны мүлдем сенімді түрде анықтауға болады. PG серверінің конфигурация опцияларының арасында бар :
Уақытты енгізу/шығару әрекеттерін қосады. Бұл параметр әдепкі бойынша өшірілген, себебі ол операциялық жүйенің ағымдағы уақытты үнемі сұрауын талап етеді, бұл кейбір платформаларда әрекеттерді айтарлықтай баяулатуы мүмкін. Сіз pg_test_timing утилитасын платформаңыздағы уақыт шығынын бағалау үшін пайдалана аласыз. Енгізу/шығару статистикасын pg_stat_database көрінісі арқылы алуға болады, EXPLAIN шығысында (BUFFERS параметрі пайдаланылғанда) және pg_stat_statements көрінісі арқылы.
Бұл опцияны жергілікті сеанста да қосуға болады:
SET track_io_timing = TRUE;Ең жақсысы, біз орындау ағашының барлық түрлендірулерін ескере отырып, бұл деректерді түсінуді және көрсетуді үйрендік:
Мұнда сіз жалпы орындау уақытының 0.790 мс-тің 0.718 мс бір бетті оқуды, 0.044 мс жазуды және барлық басқа пайдалы әрекеттерге тек 0.028 мс жұмсалғанын көре аласыз!
PostgreSQL 13 көмегімен болашақ
Жаңалықтар туралы толық шолу үшін қараңыз , және біз жоспарлардағы өзгерістер туралы арнайы айтып отырмыз.
Буферлерді жоспарлау
Жоспарлағышқа бөлінген ресурстарды есепке алу pg_stat_statements қатысы жоқ басқа патчта көрсетіледі. БУФЕРЛЕР опциясымен EXPLAIN жоспарлау кезеңінде пайдаланылған буферлердің санын хабарлайды:
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
Қосымша сұрыптау
Көптеген кілттер (k1, k2, k3…) бойынша сұрыптау қажет болған жағдайда, жоспарлаушы деректердің бірнеше бірінші кілттер (мысалы, k1 және k2) бойынша сұрыпталғанын білудің артықшылығын пайдалана алады. Бұл жағдайда сіз барлық деректерді жаңадан сұрыптай алмайсыз, бірақ оларды k1 және k2 мәндері бірдей дәйекті топтарға бөліп, k3 пернесі арқылы «қайта сұрыптаңыз».
Осылайша, бүкіл сұрыптау кішірек өлшемдегі бірнеше кезекті сұрыптауларға бөлінеді. Бұл қажетті жад көлемін азайтады, сонымен қатар барлық сұрыптау аяқталмай тұрып бірінші деректерді қайтаруға мүмкіндік береді.
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 жақсартулары
Скриншоттар барлық жерде!
Енді әрбір қойындыда жылдам мүмкіндік бар қойындының скриншотын алмасу буферіне түсіріңіз қойындының бүкіл ені мен тереңдігі үшін - «көру» оң жақ жоғарғы:
Шын мәнінде, осы басылымға арналған суреттердің көпшілігі осылай алынды.
Түйіндер бойынша ұсыныстар
Олардың көптігі ғана емес, әрқайсысы туралы сіз жасай аласыз сілтеме бойынша:
Мұрағаттан жою
Кейбіреулер қабілетін сұрады «мүлдем» жою тіпті мұрағатта жарияланбаған жоспарлар да - сәйкес белгішені басыңыз:
Жарайды, бізде бар екенін ұмытпайық онда сіз өз пікірлеріңіз бен ұсыныстарыңызды жаза аласыз.
Ақпарат көзі: www.habr.com