Page 33

Rozdzia 6. • Optymalizacja konfiguracji serwera

full_page_writes Podobnie jak przy fsync, wyczenie parametru full_page_writes zwiksza wydajno za cen wikszego ryzyka uszkodzenia bazy danych. Przed wyczeniem tego parametru naley bardzo dokadnie i ostronie przeanalizowa moliwoci systemu plików oraz uywanego sprztu, aby mie gwarancj, e nie dojdzie do czciowego zapisu stron.

commit_delay i commit_siblings Przed implementacj synchronous_commit podejmowane byy próby dodania tego rodzaju funkcji za pomoc parametrów commit_delay i commit_siblings. W wikszoci przypadków nie s to parametry efektywne do optymalizacji. Uzyskanie realnego przypieszenia poprzez dostosowanie wartoci tych parametrów jest niezwykle trudne, za to bardzo atwo mona doprowadzi do spowolnienia wykonywania kadej transakcji. Jedyny przypadek, kiedy opisywane parametry mog okaza si przydatne, dotyczy systemów o ogromnej iloci operacji wejcia-wyjcia. Ustawienie bardzo maej wartoci opó nienia moe spowodowa przeprowadzanie operacji zapisu w wikszych blokach, co czasami w poczeniu z wiksz wartoci jednostki macierzy RAID okazuje si lepszym rozwizaniem.

max_prepared_transactions Wielu uytkowników po spojrzeniu na nazw tego parametru bdzie przekonanych, e dotyczy transakcji skadowanych, czyli techniki powszechnie stosowanej w celu uniknicia wstawiania zoliwego kodu SQL, i odczuje potrzeb zwikszenia wartoci tego parametru. To jednak bdne zaoenie, omawiany parametr i transakcje skadowane nie s ze sob powizane. Transakcja skadowana to taka, która uywa polecenia PREPARE TRANSACTION w celu uycia dwuetapowego zatwierdzenia (ang. two-phase commit, 2PC). Jeeli czytelnik nie uywa tego polecenia oraz techniki 2PC, moe pozostawi dla tego parametru warto domyln. Natomiast w przypadku uywania funkcji dwuetapowego zatwierdzania konieczno zwikszenia wartoci parametru max_prepared_transaction wystpi prawdopodobnie tylko wtedy, kiedy trzeba bdzie dopasowa j do liczby pocze.

Zapytania wczajce parametry Istnieje moliwo wyczenia wielu technik stosowanych przez planist zapytania, co ma na celu uniknicie uycia niewaciwego typu zapytania. Czasami jest to stosowane jako rodzaj obejcia problemu polegajcego na tym, e PostgreSQL nie obsuguje bezporednich podpowiedzi optymalizatora dotyczcych sposobu wykonania zapytania. Czytelnik móg si spotka z przedstawionym poniej wierszem kodu jako sugerowanym sposobem wymuszenia uycia indeksów zamiast skanowania sekwencyjnego: enable_seqscan = off

Ogólnie rzecz ujmujc, to za praktyka. Zamiast niej, aby podejmowa lepsze decyzje, naley dy do poprawienia informacji przekazywanych optymalizatorowi zapyta. Temat zosta omówiony w rozdziale 10.

163

Wysoko wydajny PostgreSQL 9.0  

Masz w rękach kompletny podręcznik, przeznaczony dla średnio i bardzo zaawansowanych administratorów baz danych, którzy już używają PostgreS...

Advertisement