İcra planının əsas anlayışları: cost, rows, width

Sən SQL-sorğu yazanda, PostgreSQL onu dərhal icra etməyə başlamır. Əvvəlcə o, öz "beyni"ni — sorgu optimizatorunu işə salır və icra planı qurur. Bu plan — sanki xəritədə bir marşrut kimidir: PostgreSQL hesablayır ki, hansı addımları və hansı ardıcıllıqla etməlidir ki, məlumatları uğurla əldə etsin.

Sorgu optimizatoru sorğunun bütün mümkün icra yollarını qiymətləndirir: cədvəlin ardıcıl oxunması, indekslərdən istifadə, filtrasiya və sıralama və s. O, sorğunu icra etmək üçün ən ucuz (resurs baxımından) yolu tapmağa çalışır. Yəni, icra vaxtı ilə server resursları arasında kompromis axtarır.

İcra planının əsas parametrləri

Yaxşı, indi keçək əsas "mövzular"a — PostgreSQL-in EXPLAIN əmri nəticəsində göstərdiyi parametrlərin izahına. Başlayaq sadə bir nümunə ilə:

EXPLAIN
SELECT * FROM students WHERE age > 20;

Sən təxminən belə bir nəticə alacaqsan:

Seq Scan on students  (cost=0.00..35.00 rows=7 width=72)
  Filter: (age > 20)

Gəlin bu qəribə sözləri və rəqəmləri açaq.

1. cost (icra xərcləri)

cost — sorğunu icra etmək üçün nə qədər resurs lazım olacağını qiymətləndirir. Bu parametr iki hissədən ibarətdir:

• Startup Cost: əməliyyata başlamaq üçün xərclər (məsələn, indeksin hazırlanması).
• Total Cost: bütün əməliyyatın icrası üçün ümumi xərclər.

Nümunə:

cost=0.00..35.00

• 0.00 — bu Startup Cost-dur.
• 35.00 — bu Total Cost-dur.

cost nə qədər aşağı olsa, PostgreSQL üçün bu plan bir o qədər üstün sayılır. Amma unutma ki, cost — nisbi bir göstəricidir. O, saniyə və ya millisaniyə ilə ölçülmür, sadəcə PostgreSQL-in daxili qiymətləndirməsidir.

2. rows (gözlənilən sətr sayı)

rows göstərir ki, bu mərhələdə PostgreSQL neçə sətrin qaytarılacağını və ya işlənəcəyini gözləyir. Bizim nümunədə:

rows=7

Bu o deməkdir ki, PostgreSQL hesab edir ki, age > 20 filtri 7 sətir qaytaracaq. Bu məlumatlar PostgreSQL-in cədvəl haqqında topladığı statistikadan götürülür. Əgər statistika köhnədirsə, proqnoz səhv ola bilər. Bu da daha az optimal plana səbəb ola bilər.

3. width (sətrin baytla ölçülən eni)

width — bu mərhələdə qaytarılan hər sətrin orta ölçüsüdür, baytla ölçülür. Bizim nümunədə:

width=72

Bu o deməkdir ki, hər qaytarılan sətrin orta çəkisi 72 baytdır. width sütunlardakı məlumatların ölçüsünü və əlavə xərcləri, məsələn, sətrin identifikatorları və ya xidməti məlumatları nəzərə alır.

Bu, proqram yükləməsi kimidir. Əgər onun "çəki"si (width analoqu) böyükdürsə, yükləmə üçün daha çox vaxt lazım olacaq, hətta internetin sürətli olsa belə (cost analoqu).

İcra planının nümunə izahı

Gəlin real bir nümunəyə baxaq. Tutaq ki, bizdə students adlı cədvəl var:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER,
    major VARCHAR(50)
);

Və biz belə bir sorğu icra edirik:

EXPLAIN
SELECT * FROM students WHERE age > 20 AND major = 'CS';

Nəticə belə ola bilər:

Seq Scan on students  (cost=0.00..42.50 rows=3 width=164)
  Filter: ((age > 20) AND (major = 'CS'))

• Seq Scan: PostgreSQL students cədvəlini ardıcıl oxuyur. Yəni, hər sətri bir-bir yoxlayır.
• cost=0.00..42.50: Əməliyyatın icra xərcləri. Startup Cost 0.00-dır, ümumi xərclər isə 42.50-dir.
• rows=3: PostgreSQL gözləyir ki, age > 20 AND major = 'CS' filtri 3 sətr qaytaracaq.
• width=164: Hər sətrin orta ölçüsü 164 baytdır.

İndi artıq başa düşürsən ki, PostgreSQL necə qərar verir və sorğularda zəif yerləri necə tapmaq olar. Məsələn, əgər cost yüksəkdirsə, bu, sorğunun çox ağır olduğuna işarədir. Və ya rows çoxdursa, filtrini bir daha gözdən keçirmək lazımdır.

cost praktikada necə işləyir?

Gəlin age sütununa indeks əlavə edək:

CREATE INDEX idx_age ON students(age);

İndi sorğunu təkrar icra edirik:

EXPLAIN
SELECT * FROM students WHERE age > 20 AND major = 'CS';

Nəticə dəyişə bilər:

Bitmap Heap Scan on students  (cost=4.37..20.50 rows=3 width=164)
  Recheck Cond: (age > 20)
  Filter: (major = 'CS')
  ->  Bitmap Index Scan on idx_age  (cost=0.00..4.37 rows=20 width=0)
        Index Cond: (age > 20)

Nə dəyişdi?

• Seq Scan əvəzinə artıq Bitmap Heap Scan istifadə olunur: PostgreSQL əvvəlcə idx_age indeksində uyğun sətrləri tapır, sonra onları cədvəldən çıxarır.
• cost xeyli azaldı: indi Startup Cost 4.37-dir, Total Cost isə 20.50-dir.
• İndeks sayəsində əməliyyat daha effektiv oldu.

Vizualizasiya: Seq Scan və Index Scan fərqi

Budur, kiçik bir müqayisə cədvəli, daha aydın olsun deyə:

Gizli məqamlar və tipik səhvlər

İcra planı parametrlərindən istifadə edəndə, bəzi sürprizlərə hazır ol. Məsələn, həmişə aşağı cost daha yaxşı icra demək deyil. Əgər verilənlər bazasının statistikası köhnədirsə (məsələn, cədvəldə kütləvi dəyişiklikdən sonra), plan dəqiq olmaya bilər. Statistikaları ANALYZE əmri ilə yenilə. Bu barədə növbəti dərsdə daha ətraflı danışacağıq.

İndekslərdən lazım olan yerdə istifadə et. Amma indeksləri çoxaltma: onlar yaddaş tutur və yazma əməliyyatlarını ləngidir.