Changes between Version 4 and Version 5 of Monitoring
- Timestamp:
- 05/18/26 18:42:35 (7 days ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Monitoring
v4 v5 1 1 == Мониторинг 2 2 3 === Benchmark Report – Оптимизација на индекси и query-и во PostgreSQL 4 5 Целта на оваа анализа е да се испита влијанието на индексите, query оптимизацијата, scan стратегиите, join операциите и sorting механизмите врз перформансите на PostgreSQL при извршување на комплексни аналитички SQL query-иња. 3 === Benchmark Report – Оптимизација на индекси и query-ија во PostgreSQL 4 5 Целта на оваа анализа е да се испита влијанието на: 6 7 - индексирањето, 8 - query оптимизацијата, 9 - scan стратегиите, 10 - join операциите, 11 - sorting механизмите 12 13 врз перформансите на комплексни аналитички SQL query-и во PostgreSQL. 6 14 7 15 За секој query беа направени мерења пред оптимизација и мерења по оптимизација. Анализата е направена со: EXPLAIN ANALYZE; EXPLAIN (ANALYZE, BUFFERS). … … 46 54 }}} 47 55 48 Пред оптимизацијата, прашалникот ги дава следниве резултати: 273мс време на извршување, Seq Scan, процесирани редици 131462, одстранети редици 339478, Sort Type: External Merge. Главните проблеми се тоа што има Full Sequential Scan на player_valuations и скапо филтрирање. 56 Пред оптимизацијата беше забележано Sequential Scan на player_valuations, голем број обработени редици (≈131k+), External Merge Sort за сортирање, скапа филтрација на market_value_in_eur и 273мс време на извршување. 57 58 Ова резултираше со зголемена I/O активност и нестабилни перформанси. 49 59 50 60 Ги додаваме следниве индекси: … … 58 68 }}} 59 69 60 По оптимизацијата добиваме 248мс време на извршување, Bitmap Heap Scan и повторно за sorting се користи External Merge. Најголемата промена е тоа што за филтерот market_value_in_eur > 1000000 се користи Bitmap Index Scan, наместо скенирање на цела табела, се читаат само потребните heap pages. Сепак и покрај индексите има многу редици што се процесираат и сортингот останува главен bottleneck.70 По оптимизацијата добиваме 248мс време на извршување, Bitmap Heap Scan наместо full scan и повторно за sorting се користи External Merge. Најголемата промена е тоа што за филтерот market_value_in_eur > 1000000 се користи Bitmap Index Scan, наместо скенирање на цела табела, се читаат само потребните heap pages. Сепак и покрај индексите, кои ја подобрија селекцијата, има многу редици што се процесираат и сортингот останува главен bottleneck. 61 71 62 72 Q2 – Анализа на трансфери … … 90 100 }}} 91 101 92 П РЕД ОПТИМИЗАЦИЈАпрашалникот има време на извршување од 7.8с, чита 2.5 милиони редици, користи Seq Scan, Incremental Sort и Hash Join + Nested Loop. Главен проблем е што PostgreSQL прави SeqScan на transfers и players - прашалникот враќа голем дел од табелата. Потоа, ги додаваме следниве индекси:102 Пред оптимизацијата прашалникот има време на извршување од 7.8с, чита 2.5 милиони редици, користи Seq Scan, Incremental Sort и Hash Join + Nested Loop. Главен проблем е што PostgreSQL прави SeqScan на transfers и players - прашалникот враќа голем дел од табелата. Потоа, ги додаваме следниве индекси: 93 103 94 104 {{{ … … 103 113 }}} 104 114 105 и со мерењето ги добиваме следниве резултати: 3.5с време на извршување, што е значително подобрување, и повторно користење на Seq Scan. Сепак, главното прашање е зашто сеуште користиме Seq Scan. Кога враќаме 20% или повеќе од табелата, PostgreSQL знае дека е поевтино да користи Seq Scan од Index Scan.115 и со мерењето ги добиваме следниве резултати: 3.5с време на извршување, што е значително подобрување, и повторно користење на Seq Scan. Главното прашање е зашто сеуште користиме Seq Scan. Кога враќаме 20% или повеќе од табелата, PostgreSQL знае дека е поевтино да користи Seq Scan од Index Scan. 106 116 107 117 Q3 - Комплексен aggregation query … … 238 248 239 249 240 241 250 Оптимизацијата покажува дека индексите иако се корисни, не се доволни сами по себе. Најголемото подобрување доаѓа од редуцирање на dataset-от рано (CTE) и избегнување на join explosion. Sorting-от останува една од најскапите операции. 251 252 253 254
