PostgreSQL, karma\u015f\u0131k sorgular\u0131 optimize etmek i\u00e7in geli\u015fmi\u015f bir sorgu planlay\u0131c\u0131ya sahiptir. Bu planlay\u0131c\u0131n\u0131n en kritik g\u00f6revlerinden biri, sorgu y\u00fcr\u00fctme s\u0131ras\u0131nda her bir i\u015flemin (tablo tarama, birle\u015ftirme, s\u0131ralama vb.) tahmini maliyetini hesaplamakt\u0131r. Bu maliyet hesaplamalar\u0131n\u0131n temelini ise sat\u0131r say\u0131s\u0131 tahminleri olu\u015fturur. Ancak, bu tahminlerdeki hatalar, planlay\u0131c\u0131n\u0131n optimal olmayan bir sorgu plan\u0131 se\u00e7mesine ve dolay\u0131s\u0131yla ciddi performans sorunlar\u0131na yol a\u00e7abilir. Bu makalede, PostgreSQL’de sat\u0131r say\u0131s\u0131 tahmin hatalar\u0131n\u0131n nedenlerini, etkilerini ve bu hatalar\u0131 azaltmak i\u00e7in at\u0131labilecek pratik ad\u0131mlar\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\n
PostgreSQL sorgu planlay\u0131c\u0131s\u0131, bir sorguyu \u00e7al\u0131\u015ft\u0131rmadan \u00f6nce en verimli yolu bulmak i\u00e7in veritaban\u0131 istatistiklerine g\u00fcvenir. Bu istatistikler, tablolar\u0131n ve s\u00fctunlar\u0131n veri da\u011f\u0131l\u0131m\u0131 hakk\u0131nda bilgiler i\u00e7erir. Do\u011fru istatistikler olmadan, planlay\u0131c\u0131 “k\u00f6r” kal\u0131r ve yanl\u0131\u015f kararlar verebilir.<\/p>\n
Sorgu planlay\u0131c\u0131s\u0131, bir SQL sorgusu geldi\u011finde, sorguyu farkl\u0131 \u015fekillerde y\u00fcr\u00fctebilecek potansiyel planlar olu\u015fturur. Her bir plan i\u00e7in, disk I\/O, CPU kullan\u0131m\u0131 ve a\u011f trafi\u011fi gibi fakt\u00f6rleri hesaba katarak bir maliyet tahmini yapar. Bu maliyet tahminlerinin merkezinde, her bir ad\u0131mda i\u015flenecek tahmini sat\u0131r say\u0131s\u0131 yer al\u0131r. \u00d6rne\u011fin, bir Yanl\u0131\u015f sat\u0131r say\u0131s\u0131 tahminleri, sorgu planlay\u0131c\u0131s\u0131n\u0131n yanl\u0131\u015f bir Veritaban\u0131ndaki veriler s\u00fcrekli de\u011fi\u015fir: yeni sat\u0131rlar eklenir, mevcut sat\u0131rlar g\u00fcncellenir veya silinir. Bu de\u011fi\u015fiklikler, veri da\u011f\u0131l\u0131m\u0131n\u0131 ve dolay\u0131s\u0131yla istatistikleri etkiler. E\u011fer istatistikler g\u00fcncel de\u011filse, planlay\u0131c\u0131 eski ve yanl\u0131\u015f bilgilere dayanarak karar verir. Bu nedenle, istatistiklerin d\u00fczenli olarak g\u00fcncellenmesi, planlay\u0131c\u0131n\u0131n her zaman en do\u011fru bilgilere sahip olmas\u0131n\u0131 sa\u011flar.<\/p>\n PostgreSQL’de istatistiklerin g\u00fcncel tutulmas\u0131n\u0131n ana mekanizmas\u0131 PostgreSQL, <\/code> <\/code> <\/code><\/p>\n \u0130statistiklerin do\u011frulu\u011funu etkileyen bir\u00e7ok fakt\u00f6r bulunur. Bu fakt\u00f6rleri anlamak ve bunlara uygun \u00e7\u00f6z\u00fcmler uygulamak, tahmin hatalar\u0131n\u0131 azaltmada kilit rol oynar.<\/p>\n Bir s\u00fctundaki veriler e\u015fit da\u011f\u0131lmad\u0131\u011f\u0131nda (\u00f6rne\u011fin, bir s\u00fctunun de\u011ferlerinin %90'\u0131 tek bir de\u011fere sahipse), bu duruma veri da\u011f\u0131l\u0131m\u0131 (data skew) denir. Standart istatistikler, bu t\u00fcr bir da\u011f\u0131l\u0131m\u0131 do\u011fru bir \u015fekilde temsil etmekte zorlanabilir. Bu, sorgu planlay\u0131c\u0131s\u0131n\u0131n, belirli bir de\u011feri filtreleyen sorgular i\u00e7in sat\u0131r say\u0131s\u0131 tahminlerini yanl\u0131\u015f yapmas\u0131na neden olur.<\/p>\n Sorgularda kullan\u0131lan karma\u015f\u0131k fonksiyonlar, \u00f6zel operat\u00f6rler veya alt sorgular, planlay\u0131c\u0131n\u0131n tahmin yetene\u011fini zorlayabilir. PostgreSQL, bu t\u00fcr ifadelerin sonu\u00e7lar\u0131n\u0131 \u00f6nceden bilemez ve genellikle varsay\u0131lan tahmin de\u011ferleri kullan\u0131r, bu da hatalara yol a\u00e7ar. \u00d6rne\u011fin, bir fonksiyondan d\u00f6nen de\u011fer \u00fczerinde filtreleme yap\u0131l\u0131yorsa, planlay\u0131c\u0131 fonksiyonun ne kadar sat\u0131r d\u00f6nd\u00fcrece\u011fini tahmin edemeyebilir.<\/p>\n \u00c7ok s\u0131k ekleme, g\u00fcncelleme veya silme i\u015flemleri g\u00f6ren tablolar\u0131n istatistikleri h\u0131zla eskiyebilir. \u00d6zellikle metin tabanl\u0131 s\u00fctunlarda (TEXT, VARCHAR) veya JSONB gibi karma\u015f\u0131k veri tiplerinde, varsay\u0131lan istatistik toplama y\u00f6ntemleri her zaman yeterli olmayabilir. Bu t\u00fcr s\u00fctunlar i\u00e7in \u00f6zel istatistik hedefleri veya geni\u015fletilmi\u015f istatistikler d\u00fc\u015f\u00fcn\u00fclmelidir.<\/p>\n Tahmin hatalar\u0131n\u0131 tespit etmenin en etkili yolu, sorgu planlar\u0131n\u0131 incelemek ve istatistik tablolar\u0131n\u0131 do\u011frudan sorgulamakt\u0131r.<\/p>\n <\/code> <\/code> Standart <\/code> Bu komut, belirli bir tablonun belirli bir s\u00fctunu i\u00e7in istatistik hedefi belirlemenizi sa\u011flar. Bu, <\/code><\/p>\n PostgreSQL 10 ile tan\u0131t\u0131lan geni\u015fletilmi\u015f istatistikler, birden fazla s\u00fctun aras\u0131ndaki korelasyonu (ba\u011f\u0131nt\u0131y\u0131) veya fonksiyonel ba\u011f\u0131ml\u0131l\u0131klar\u0131 analiz etme yetene\u011fi sunar. Bu, \u00f6zellikle birden fazla s\u00fctunu i\u00e7eren <\/code> Baz\u0131 \u00f6zel veritaban\u0131 yap\u0131lar\u0131 ve kullan\u0131m senaryolar\u0131, istatistik toplama ve tahmin do\u011frulu\u011fu konusunda ek zorluklar \u00e7\u0131karabilir.<\/p>\n B\u00f6l\u00fcmlenmi\u015f tablolar, mant\u0131ksal olarak tek bir tablo gibi g\u00f6r\u00fcnse de fiziksel olarak birden fazla alt tabloya ayr\u0131lm\u0131\u015ft\u0131r. PostgreSQL, her bir b\u00f6l\u00fcm i\u00e7in ayr\u0131 ayr\u0131 istatistik toplar. Kullan\u0131c\u0131 tan\u0131ml\u0131 veri tipleri veya \u00f6zel operat\u00f6rler kullan\u0131ld\u0131\u011f\u0131nda, PostgreSQL'in bunlar hakk\u0131nda do\u011fal olarak istatistik toplama yetene\u011fi s\u0131n\u0131rl\u0131d\u0131r. Bu durumlarda, planlay\u0131c\u0131 genellikle varsay\u0131lan tahmin de\u011ferleri kullan\u0131r. Performans kritik sorgularda bu t\u00fcr yap\u0131lar\u0131 kullan\u0131rken, Haz\u0131rlanm\u0131\u015f ifadeler, ilk y\u00fcr\u00fctmede bir plan olu\u015fturur ve sonraki y\u00fcr\u00fctmelerde bu plan\u0131 tekrar kullan\u0131r. E\u011fer ilk planlama s\u0131ras\u0131nda kullan\u0131lan parametre de\u011ferleri, sonraki y\u00fcr\u00fctmelerdeki tipik parametre de\u011ferlerinden \u00e7ok farkl\u0131ysa, planlay\u0131c\u0131 suboptimal bir plan olu\u015fturabilir. PostgreSQL, bu sorunu azaltmak i\u00e7in \"genel\" ve \"\u00f6zel\" planlar aras\u0131nda ge\u00e7i\u015f yapabilir, ancak yine de dikkatli olunmal\u0131d\u0131r. PostgreSQL'de sat\u0131r say\u0131s\u0131 tahmin hatalar\u0131n\u0131 azaltmak tek seferlik bir g\u00f6rev de\u011fildir; s\u00fcrekli bir izleme ve iyile\u015ftirme s\u00fcrecidir.<\/p>\n D\u00fczenli olarak Veritaban\u0131 i\u015f y\u00fckleri zamanla de\u011fi\u015febilir. Yeni sorgular, yeni veri da\u011f\u0131l\u0131mlar\u0131 ortaya \u00e7\u0131kabilir. Bu nedenle, istatistik toplama stratejileri ve PostgreSQL'de sat\u0131r say\u0131s\u0131 tahmin hatalar\u0131n\u0131 azaltmak, veritaban\u0131 performans\u0131n\u0131 optimize etmenin temel ta\u015flar\u0131ndan biridir. Do\u011fru ve g\u00fcncel veritaban\u0131 istatistikleri, sorgu planlay\u0131c\u0131s\u0131n\u0131n en verimli y\u00fcr\u00fctme planlar\u0131n\u0131 se\u00e7mesini sa\u011flayarak sorgu s\u00fcrelerini k\u0131salt\u0131r ve kaynak kullan\u0131m\u0131n\u0131 optimize eder. Genellikle Bu de\u011feri art\u0131rmak, daha do\u011fru istatistikler toplaman\u0131z\u0131 sa\u011flar ancak Hay\u0131r, Yanl\u0131\u015f tahminler, sadece yava\u015f sorgulara de\u011fil, ayn\u0131 zamanda gereksiz CPU ve bellek kullan\u0131m\u0131na, disk I\/O'sunun artmas\u0131na ve hatta veritaban\u0131 sunucusunun genel stabilitesini etkileyen kaynak t\u00fckenmelerine de neden olabilir. Optimal olmayan bir plan, daha fazla ge\u00e7ici dosya olu\u015fturabilir veya daha fazla bellek kullanabilir.<\/p>\n \u00c7o\u011fu durumda JOIN<\/code> i\u015flemi i\u00e7in hangi tablonun d\u0131\u015f, hangisinin i\u00e7 tablo olaca\u011f\u0131na karar verirken, sat\u0131r say\u0131s\u0131 tahminleri hayati rol oynar.<\/p>\nYanl\u0131\u015f Tahminlerin Performansa Etkisi<\/h4>\n
JOIN<\/code> stratejisi (\u00f6rne\u011fin, Hash Join<\/code> yerine Nested Loop<\/code> se\u00e7imi), yanl\u0131\u015f indeks kullan\u0131m\u0131 veya gereksiz yere b\u00fcy\u00fck bir ge\u00e7ici dosya olu\u015fturma gibi suboptimal kararlar almas\u0131na neden olabilir. Bu durum, sorgular\u0131n beklenenden \u00e7ok daha uzun s\u00fcrmesine, CPU ve bellek kaynaklar\u0131n\u0131n israf edilmesine ve genel veritaban\u0131 performans\u0131n\u0131n d\u00fc\u015fmesine yol a\u00e7ar.<\/p>\n\u0130statistiklerin G\u00fcncelli\u011fi Neden \u00d6nemli?<\/h4>\n
VACUUM ve ANALYZE \u0130\u015flemlerinin Do\u011fru Kullan\u0131m\u0131<\/h3>\n
ANALYZE<\/code> komutudur. VACUUM<\/code> ise \u00f6l\u00fc sat\u0131rlar\u0131 temizleyerek disk alan\u0131n\u0131 geri kazan\u0131r ve ANALYZE<\/code> ile birlikte \u00e7al\u0131\u015farak istatistiklerin do\u011frulu\u011funu art\u0131rabilir.<\/p>\nAUTOANALYZE’\u0131n Rol\u00fc ve Ayarlar\u0131<\/h4>\n
autovacuum<\/code> demonu arac\u0131l\u0131\u011f\u0131yla otomatik olarak VACUUM<\/code> ve ANALYZE<\/code> i\u015flemlerini \u00e7al\u0131\u015ft\u0131r\u0131r. autovacuum<\/code> ayarlar\u0131, bu i\u015flemlerin ne s\u0131kl\u0131kta ve hangi ko\u015fullar alt\u0131nda tetiklenece\u011fini belirler. \u00d6zellikle autovacuum_analyze_scale_factor<\/code> ve autovacuum_analyze_threshold<\/code> parametreleri, bir tablodaki eklenen, g\u00fcncellenen veya silinen sat\u0131r say\u0131s\u0131n\u0131n belirli bir e\u015fi\u011fi a\u015ft\u0131\u011f\u0131nda ANALYZE<\/code> i\u015fleminin tetiklenmesini sa\u011flar.<\/p>\n-- Mevcut autovacuum ayarlar\u0131n\u0131 kontrol etme\nSHOW autovacuum_analyze_scale_factor;\nSHOW autovacuum_analyze_threshold;<\/pre>\n
\nBu de\u011ferlerin i\u015f y\u00fck\u00fcn\u00fcze uygun \u015fekilde ayarlanmas\u0131, istatistiklerin zaman\u0131nda g\u00fcncellenmesi i\u00e7in kritik \u00f6neme sahiptir. \u00c7ok aktif tablolarda bu e\u015fikler daha d\u00fc\u015f\u00fck tutulabilir.<\/p>\nManuel ANALYZE Ne Zaman Gerekli?<\/h4>\n
AUTOANALYZE<\/code> \u00e7o\u011fu senaryoda yeterli olsa da, baz\u0131 durumlarda manuel ANALYZE<\/code> \u00e7al\u0131\u015ft\u0131rmak gerekebilir:
\n* B\u00fcy\u00fck veri y\u00fcklemelerinden (bulk inserts) veya g\u00fcncellemelerden sonra.
\n* autovacuum<\/code> ayarlar\u0131n\u0131n yetersiz kald\u0131\u011f\u0131, \u00e7ok h\u0131zl\u0131 de\u011fi\u015fen tablolarda.
\n* Belirli bir sorgunun performans sorunlar\u0131 ya\u015fad\u0131\u011f\u0131 ve EXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131nda b\u00fcy\u00fck tahmin hatalar\u0131 g\u00f6r\u00fcld\u00fc\u011f\u00fcnde.
\n* Yeni bir indeks olu\u015fturuldu\u011funda veya mevcut bir indeks yeniden olu\u015fturuldu\u011funda.<\/p>\n-- T\u00fcm veritaban\u0131n\u0131 analiz etme\nANALYZE VERBOSE;\n\n-- Belirli bir tabloyu analiz etme\nANALYZE VERBOSE my_table;\n\n-- Belirli bir tablonun belirli bir s\u00fctununu analiz etme\nANALYZE VERBOSE my_table (my_column);<\/pre>\n
\nVERBOSE<\/code> anahtar kelimesi, ANALYZE<\/code> i\u015fleminin ilerlemesi ve tamamland\u0131\u011f\u0131nda hangi tablolar\u0131n i\u015flendi\u011fi hakk\u0131nda daha fazla bilgi sa\u011flar.<\/p>\nVACUUM ve ANALYZE Aras\u0131ndaki Fark<\/h4>\n
VACUUM<\/code>, \u00f6l\u00fc sat\u0131rlar\u0131 (eski s\u00fcr\u00fcmlerini) i\u015faretler ve disk alan\u0131n\u0131n yeniden kullan\u0131labilir hale gelmesini sa\u011flar. ANALYZE<\/code> ise tablonun ve s\u00fctunlar\u0131n istatistiklerini toplar. \u0130kisi de performans i\u00e7in \u00f6nemlidir, ancak farkl\u0131 g\u00f6revleri vard\u0131r. VACUUM<\/code> olmadan ANALYZE<\/code> \u00e7al\u0131\u015ft\u0131r\u0131labilir, ancak VACUUM<\/code> i\u015flemi bazen ANALYZE<\/code> ile birlikte \u00e7al\u0131\u015farak daha do\u011fru istatistikler toplanmas\u0131na yard\u0131mc\u0131 olabilir, \u00f6zellikle \u00e7ok say\u0131da \u00f6l\u00fc sat\u0131r\u0131n oldu\u011fu tablolarda.<\/p>\npg_stat_activity ile \u0130zleme<\/h4>\n
pg_stat_activity<\/code> g\u00f6r\u00fcn\u00fcm\u00fc, arka planda \u00e7al\u0131\u015fan autovacuum<\/code> i\u015flemlerini izlemenizi sa\u011flar. Bu, ANALYZE<\/code> i\u015flemlerinin ne zaman ve hangi tablolar \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak i\u00e7in faydal\u0131d\u0131r.<\/p>\nSELECT datname, usename, state, query\nFROM pg_stat_activity\nWHERE query LIKE 'autovacuum: ANALYZE%';<\/pre>\n\u0130statistikleri Etkileyen Fakt\u00f6rler ve \u00c7\u00f6z\u00fcmler<\/h3>\n
Veri Da\u011f\u0131l\u0131m\u0131 (Data Skew) ve Etkileri<\/h4>\n
Karma\u015f\u0131k Sorgular ve Fonksiyonlar<\/h4>\n
S\u00fcrekli De\u011fi\u015fen Veriler<\/h4>\n
AUTOANALYZE<\/code> ayarlar\u0131 bu durumu y\u00f6netmek i\u00e7in \u00f6nemlidir, ancak bazen manuel m\u00fcdahale veya daha agresif AUTOANALYZE<\/code> konfig\u00fcrasyonlar\u0131 gerekebilir.<\/p>\nVeri Tiplerinin Etkisi<\/h4>\n
pg_stats ve EXPLAIN ANALYZE ile Sorun Tespiti<\/h3>\n
EXPLAIN ANALYZE Okuma ve Yorumlama<\/h4>\n
EXPLAIN ANALYZE<\/code> komutu, bir sorgunun ger\u00e7ekte nas\u0131l y\u00fcr\u00fct\u00fcld\u00fc\u011f\u00fcn\u00fc ve her bir ad\u0131m i\u00e7in hem tahmini hem de ger\u00e7ek sat\u0131r say\u0131lar\u0131n\u0131, maliyetleri ve s\u00fcreleri g\u00f6sterir.<\/p>\nEXPLAIN ANALYZE\nSELECT *\nFROM my_table mt\nJOIN another_table at ON mt.id = at.mt_id\nWHERE mt.status = 'active' AND at.value > 100;<\/pre>\n
\nEXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131nda, rows=<\/code> (tahmini sat\u0131r say\u0131s\u0131) ve actual rows=<\/code> (ger\u00e7ekle\u015fen sat\u0131r say\u0131s\u0131) de\u011ferleri aras\u0131ndaki b\u00fcy\u00fck farklar, tahmin hatas\u0131n\u0131n bir g\u00f6stergesidir. \u00d6zellikle Join<\/code> ve Filter<\/code> d\u00fc\u011f\u00fcmlerindeki b\u00fcy\u00fck farklar, sorunun kayna\u011f\u0131na i\u015faret eder.<\/p>\npg_stats G\u00f6r\u00fcn\u00fcm\u00fcn\u00fcn Kullan\u0131m\u0131<\/h4>\n
pg_stats<\/code> g\u00f6r\u00fcn\u00fcm\u00fc, PostgreSQL'in her s\u00fctun i\u00e7in toplad\u0131\u011f\u0131 istatistikleri i\u00e7erir. Bu g\u00f6r\u00fcn\u00fcm, bir s\u00fctunun veri da\u011f\u0131l\u0131m\u0131n\u0131, en yayg\u0131n de\u011ferleri (most_common_vals) ve histogram verilerini g\u00f6rmenizi sa\u011flar.<\/p>\nSELECT tablename, attname, inherited, n_distinct,\n most_common_vals, most_common_freqs, histogram_bounds\nFROM pg_stats\nWHERE tablename = 'my_table' AND attname = 'my_column';<\/pre>\n
\nBu bilgiler, bir s\u00fctundaki veri da\u011f\u0131l\u0131m\u0131n\u0131n sorgu planlay\u0131c\u0131 taraf\u0131ndan nas\u0131l alg\u0131land\u0131\u011f\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olur. E\u011fer most_common_vals<\/code> veya histogram_bounds<\/code> de\u011ferleri, ger\u00e7ek veri da\u011f\u0131l\u0131m\u0131n\u0131z\u0131 do\u011fru yans\u0131tm\u0131yorsa, bu bir istatistik toplama sorununa i\u015faret edebilir.<\/p>\nActual vs. Estimated Sat\u0131r Say\u0131lar\u0131<\/h4>\n
EXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131nda rows<\/code> ve actual rows<\/code> de\u011ferleri aras\u0131ndaki oran genellikle 10 kat veya daha fazla sapma g\u00f6steriyorsa, bu ciddi bir tahmin hatas\u0131d\u0131r. Bu durum, planlay\u0131c\u0131n\u0131n yanl\u0131\u015f bir strateji se\u00e7mesine ve sorgunun yava\u015flamas\u0131na neden olabilir.<\/p>\nGeli\u015fmi\u015f \u0130statistik Ayarlar\u0131 ve Geni\u015fletilmi\u015f \u0130statistikler<\/h3>\n
ANALYZE<\/code> i\u015flemleri baz\u0131 karma\u015f\u0131k senaryolarda yetersiz kalabilir. PostgreSQL, bu durumlar i\u00e7in daha geli\u015fmi\u015f istatistik toplama mekanizmalar\u0131 sunar.<\/p>\ndefault_statistics_target<\/code> Parametresi<\/h4>\ndefault_statistics_target<\/code> parametresi, ANALYZE<\/code> komutunun her s\u00fctun i\u00e7in toplayaca\u011f\u0131 istatistik \u00f6rneklerinin say\u0131s\u0131n\u0131 kontrol eder. Varsay\u0131lan de\u011feri 100'd\u00fcr. Daha y\u00fcksek bir de\u011fer, daha fazla \u00f6rnek toplanmas\u0131n\u0131 ve dolay\u0131s\u0131yla daha do\u011fru istatistikler elde edilmesini sa\u011flar, ancak ANALYZE<\/code> i\u015fleminin daha uzun s\u00fcrmesine ve pg_stats<\/code> tablosunda daha fazla yer kaplamas\u0131na neden olur.<\/p>\n-- Global olarak istatistik hedefi ayarlama (dikkatli kullan\u0131lmal\u0131)\nALTER SYSTEM SET default_statistics_target = 200;\n\n-- Belirli bir s\u00fctun i\u00e7in istatistik hedefi ayarlama\nALTER TABLE my_table ALTER COLUMN my_column SET STATISTICS 500;<\/pre>\n
\n\u00d6zellikle veri da\u011f\u0131l\u0131m\u0131n\u0131n \u00e7ok \u00e7arp\u0131k oldu\u011fu veya y\u00fcksek kardinaliteye sahip s\u00fctunlar i\u00e7in bu de\u011feri art\u0131rmak faydal\u0131 olabilir.<\/p>\nALTER TABLE ... ALTER COLUMN ... SET STATISTICS<\/code><\/h4>\ndefault_statistics_target<\/code> de\u011ferini t\u00fcm veritaban\u0131 i\u00e7in de\u011fi\u015ftirmek yerine, sadece sorunlu s\u00fctunlar i\u00e7in daha detayl\u0131 istatistikler toplaman\u0131za olanak tan\u0131r.<\/p>\nALTER TABLE products ALTER COLUMN category_id SET STATISTICS 300;\nANALYZE products (category_id);<\/pre>\nCREATE STATISTICS<\/code> ile Geni\u015fletilmi\u015f \u0130statistikler<\/h4>\nWHERE<\/code> ko\u015fullar\u0131na sahip sorgularda tahmin do\u011frulu\u011funu art\u0131rabilir.
\n* Ba\u011f\u0131nt\u0131 \u0130statistikleri (Correlation Statistics):<\/strong> \u0130ki veya daha fazla s\u00fctunun birlikte nas\u0131l de\u011fi\u015fti\u011fini \u00f6l\u00e7er.
\n* Fonksiyonel Ba\u011f\u0131ml\u0131l\u0131k \u0130statistikleri (Functional Dependency Statistics):<\/strong> Bir s\u00fctunun de\u011ferinin ba\u015fka bir s\u00fctunun de\u011feri taraf\u0131ndan belirlendi\u011fi durumlar\u0131 tespit eder.<\/p>\n-- \u0130ki s\u00fctun aras\u0131ndaki ba\u011f\u0131nt\u0131y\u0131 analiz eden istatistik olu\u015fturma\nCREATE STATISTICS s_product_category ON product_id, category_id FROM products;\n\n-- Analiz i\u015flemini \u00e7al\u0131\u015ft\u0131rma\nANALYZE products;<\/pre>\n
\nGeni\u015fletilmi\u015f istatistikler, \u00f6zellikle AND<\/code> ko\u015fullar\u0131yla birle\u015ftirilmi\u015f filtrelerde veya birden fazla s\u00fctunu i\u00e7eren GROUP BY<\/code> veya ORDER BY<\/code> i\u015flemlerinde tahmin hatalar\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir.<\/p>\n\u00c7oklu S\u00fctun Korelasyonlar\u0131<\/h4>\n
CREATE STATISTICS<\/code> ile olu\u015fturulan \u00e7oklu s\u00fctun istatistikleri, sorgu planlay\u0131c\u0131s\u0131n\u0131n, birden fazla s\u00fctun \u00fczerinde ayn\u0131 anda uygulanan filtrelerin ne kadar se\u00e7ici olaca\u011f\u0131n\u0131 daha do\u011fru bir \u015fekilde tahmin etmesini sa\u011flar. \u00d6rne\u011fin, WHERE country = 'USA' AND city = 'New York'<\/code> gibi bir sorguda, country<\/code> ve city<\/code> s\u00fctunlar\u0131 aras\u0131nda g\u00fc\u00e7l\u00fc bir korelasyon vard\u0131r. Standart istatistikler bu korelasyonu g\u00f6z ard\u0131 ederken, geni\u015fletilmi\u015f istatistikler bunu hesaba katarak \u00e7ok daha do\u011fru bir tahmin yapabilir.<\/p>\n\u00d6zel Durumlar ve Dikkat Edilmesi Gerekenler<\/h3>\n
B\u00f6l\u00fcmlenmi\u015f Tablolar (Partitioned Tables)<\/h4>\n
ANALYZE<\/code> komutunu ana tablo \u00fczerinde \u00e7al\u0131\u015ft\u0131rmak, t\u00fcm b\u00f6l\u00fcmlerin analiz edilmesini sa\u011flar. Ancak, \u00f6zellikle yeni b\u00f6l\u00fcmler eklendi\u011finde veya mevcut b\u00f6l\u00fcmlerde b\u00fcy\u00fck veri de\u011fi\u015fiklikleri oldu\u011funda, ANALYZE<\/code> i\u015fleminin do\u011fru \u015fekilde tetiklendi\u011finden emin olmak \u00f6nemlidir.<\/p>\nYabanc\u0131 Tablolar (Foreign Tables)<\/h4>\n
FOREIGN DATA WRAPPER<\/code> (FDW) kullan\u0131larak eri\u015filen yabanc\u0131 tablolar i\u00e7in istatistik toplama, kullan\u0131lan FDW'ye ve uzak veritaban\u0131n\u0131n yeteneklerine ba\u011fl\u0131d\u0131r. Baz\u0131 FDW'ler, uzak sunucudan istatistikleri alabilirken, baz\u0131lar\u0131 varsay\u0131lan tahmin de\u011ferleri kullanmak zorunda kalabilir. Bu durumda, EXPLAIN ANALYZE<\/code> ile tahmin hatalar\u0131n\u0131 izlemek ve gerekirse uzak veritaban\u0131nda istatistiklerin g\u00fcncel oldu\u011fundan emin olmak \u00f6nemlidir.<\/p>\n\u00d6zel Veri Tipleri ve Operat\u00f6rler<\/h4>\n
EXPLAIN ANALYZE<\/code> ile dikkatli izleme ve gerekirse sorgu ipu\u00e7lar\u0131 (ancak PostgreSQL'de do\u011frudan ipucu mekanizmas\u0131 yoktur, sorguyu yeniden yazmak gerekir) veya manuel ayarlamalar d\u00fc\u015f\u00fcn\u00fclmelidir.<\/p>\nHaz\u0131rlanm\u0131\u015f \u0130fadeler (Prepared Statements)<\/h4>\n
PREPARE<\/code> ve EXECUTE<\/code> kullan\u0131rken, EXPLAIN ANALYZE<\/code> ile planlar\u0131 kontrol etmek \u00f6nemlidir.<\/p>\n\u0130zleme ve S\u00fcrekli \u0130yile\u015ftirme<\/h3>\n
Sorgu Performans\u0131n\u0131 \u0130zleme Ara\u00e7lar\u0131<\/h4>\n
pg_stat_statements<\/code> mod\u00fcl\u00fc, en yava\u015f ve en s\u0131k \u00e7al\u0131\u015fan sorgular\u0131 belirlemek i\u00e7in paha bi\u00e7ilmez bir ara\u00e7t\u0131r. Bu mod\u00fcl sayesinde, tahmin hatalar\u0131n\u0131n en \u00e7ok hangi sorgularda sorun yaratt\u0131\u011f\u0131n\u0131 tespit edebilirsiniz. Ayr\u0131ca, \u00fc\u00e7\u00fcnc\u00fc taraf izleme ara\u00e7lar\u0131 (Prometheus, Grafana, PMM vb.) veritaban\u0131 performans\u0131n\u0131 ve istatistik g\u00fcncellemelerini takip etmek i\u00e7in kullan\u0131labilir.<\/p>\nPeriyodik \u0130statistik Kontrolleri<\/h4>\n
pg_stats<\/code> g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc kontrol etmek ve EXPLAIN ANALYZE<\/code> ile kritik sorgular\u0131n planlar\u0131n\u0131 incelemek, istatistiklerin g\u00fcncelli\u011fini ve do\u011frulu\u011funu sa\u011flamak i\u00e7in \u00f6nemlidir. \u00d6zellikle b\u00fcy\u00fck veri de\u011fi\u015fiklikleri veya uygulama g\u00fcncellemelerinden sonra bu kontrollerin yap\u0131lmas\u0131 \u00f6nerilir.<\/p>\nDe\u011fi\u015fen \u0130\u015f Y\u00fcklerine Adaptasyon<\/h4>\n
autovacuum<\/code> ayarlar\u0131 periyodik olarak g\u00f6zden ge\u00e7irilmeli ve de\u011fi\u015fen ihtiya\u00e7lara g\u00f6re ayarlanmal\u0131d\u0131r.<\/p>\nSonu\u00e7<\/h3>\n
ANALYZE<\/code> ve VACUUM<\/code> i\u015flemlerinin do\u011fru kullan\u0131m\u0131, default_statistics_target<\/code> gibi parametrelerin ak\u0131ll\u0131ca ayarlanmas\u0131 ve CREATE STATISTICS<\/code> ile geni\u015fletilmi\u015f istatistiklerin uygulanmas\u0131, bu hatalar\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde azaltabilir. EXPLAIN ANALYZE<\/code> ve pg_stats<\/code> gibi ara\u00e7larla s\u00fcrekli izleme ve periyodik kontroller, bu s\u00fcrecin ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r. Unutmay\u0131n, iyi bir veritaban\u0131 performans\u0131, do\u011fru istatistiklerle ba\u015flar.<\/p>\nSSS (S\u0131k Sorulan Sorular)<\/h3>\n
ANALYZE ne s\u0131kl\u0131kla \u00e7al\u0131\u015ft\u0131r\u0131lmal\u0131?<\/h4>\n
AUTOANALYZE<\/code> ayarlar\u0131 (\u00f6zellikle autovacuum_analyze_scale_factor<\/code> ve autovacuum_analyze_threshold<\/code>) \u00e7o\u011fu durumda yeterlidir. Ancak, b\u00fcy\u00fck veri y\u00fcklemelerinden, \u00f6nemli veri de\u011fi\u015fikliklerinden sonra veya kritik sorgularda performans d\u00fc\u015f\u00fc\u015f\u00fc fark edildi\u011finde manuel ANALYZE<\/code> \u00e7al\u0131\u015ft\u0131rmak faydal\u0131 olabilir. \u00c7ok dinamik tablolarda AUTOANALYZE<\/code> e\u015fiklerini d\u00fc\u015f\u00fcrmek gerekebilir.<\/p>\ndefault_statistics_target de\u011ferini neye g\u00f6re ayarlamal\u0131y\u0131m?<\/h4>\n
ANALYZE<\/code> s\u00fcresini ve pg_stats<\/code> boyutunu art\u0131r\u0131r. Varsay\u0131lan 100 de\u011feri \u00e7o\u011fu s\u00fctun i\u00e7in yeterlidir. Ancak, veri da\u011f\u0131l\u0131m\u0131 \u00e7ok \u00e7arp\u0131k olan veya y\u00fcksek kardinaliteye sahip s\u00fctunlar i\u00e7in bu de\u011feri 200-500 aral\u0131\u011f\u0131na \u00e7\u0131karmak faydal\u0131 olabilir. T\u00fcm veritaban\u0131 i\u00e7in global olarak art\u0131rmak yerine, ALTER TABLE ... ALTER COLUMN ... SET STATISTICS<\/code> ile sadece sorunlu s\u00fctunlar i\u00e7in ayarlamak daha iyi bir yakla\u015f\u0131md\u0131r.<\/p>\nCREATE STATISTICS her zaman gerekli mi?<\/h4>\n
CREATE STATISTICS<\/code> her zaman gerekli de\u011fildir. \u00d6zellikle birden fazla s\u00fctun aras\u0131nda g\u00fc\u00e7l\u00fc korelasyonun oldu\u011fu ve bu s\u00fctunlar\u0131n birlikte s\u0131k\u00e7a filtreleme ko\u015fullar\u0131nda kullan\u0131ld\u0131\u011f\u0131 durumlarda \u00e7ok faydal\u0131d\u0131r. EXPLAIN ANALYZE<\/code> \u00e7\u0131kt\u0131s\u0131nda bu t\u00fcr sorgularda b\u00fcy\u00fck tahmin hatalar\u0131 g\u00f6r\u00fcyorsan\u0131z, geni\u015fletilmi\u015f istatistikleri denemeyi d\u00fc\u015f\u00fcnebilirsiniz.<\/p>\nYanl\u0131\u015f tahminler sadece yava\u015f sorgulara m\u0131 neden olur?<\/h4>\n
PostgreSQL'in istatistikleri otomatik olarak g\u00fcncellemesi yeterli mi?<\/h4>\n
AUTOANALYZE<\/code> yeterli olsa da, baz\u0131 senaryolarda manuel m\u00fcdahale gerekebilir. \u00d6zellikle b\u00fcy\u00fck veri y\u00fcklemeleri sonras\u0131 veya AUTOANALYZE<\/code> e\u015fiklerinin \u00e7ok y\u00fcksek ayarland\u0131\u011f\u0131 durumlarda istatistikler g\u00fcncel kalmayabilir. Sisteminizin i\u015f y\u00fck\u00fcn\u00fc ve veri de\u011fi\u015fim h\u0131z\u0131n\u0131 anlamak, AUTOANALYZE<\/code> ayarlar\u0131n\u0131n yeterli olup olmad\u0131\u011f\u0131n\u0131 belirlemek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n","protected":false},"excerpt":{"rendered":"PostgreSQL’de Sat\u0131r Say\u0131s\u0131 Tahmin Hatalar\u0131n\u0131 Azaltma: Performans \u0130\u00e7in Kritik Ad\u0131mlar\nPostgreSQL, karma\u015f\u0131k sorgular\u0131 optimize etmek i\u00e7in geli\u015fmi…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[644],"tags":[],"class_list":{"0":"post-38717","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-postgresql","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n