1.
от това, което прочетох, хешира заявката и я запазва в DB, като записва текста във FS. Така че следващата грижа е по-очаквана от претоварената споделена памет:
хешът на текста е толкова по-малък от текста, че мисля, че не трябва да се притеснявате за консумацията на памет за разширението при сравняване на дълги заявки. Особено като се знае, че разширението използва Query Analyzer (който ще работи за ВСЯКИ запитване ВЪВСЕКИ ):
Настройка на pg_stat_statements.max Вярвам, че 10 пъти по-големи трябва да отнемат 10 пъти повече споделена памет. Израстъците трябва да салинейни . В документацията не пише така , но логично би трябвало да е така.
Няма отговор дали е безопасно или не да зададете отделна стойност на настройката, защото няма данни за други конфигурационни стойности и HW, които имате. Но тъй като растежът трябва да бъде линеен, помислете за този отговор:"ако го зададете на 5K и времето за изпълнение на заявката не е нараснало почти нищо, тогава настройването му на 50K ще го удължи почти нищо пъти по десет". Между другото, въпросът ми - кой ще копае 50 000 бавни твърдения? :)
2.
Това разширение вече прави предварително агрегиране за изявление „обезценен“. Можете да го изберете направо в БД, така че преместването на данни в друга БД и избирането им там ще ви даде само предимството да разтоварите оригиналната БД и да заредите друга. С други думи, вие спестявате 50MB за заявка на оригинала, но харчите същото за друга. Има ли смисъл? За мен – да. Това правя и аз. Но също така запазвам планове за изпълнение за израз (което не е част от разширението pg_stat_statements). Вярвам, че зависи от това какво имате и какво имате. Определено няма нужда от това само поради редица запитвания. Отново, освен ако нямате толкова голям файл, че разширението може
