1.
fra hvad jeg har læst, hashes forespørgslen og gemmer den i DB og gemmer teksten til FS. Så næste bekymring er mere forventet end overbelastet delt hukommelse:
hashen af tekst er så meget mindre end tekst, at jeg tror, du ikke skal bekymre dig om forbrug af udvidelseshukommelse ved at sammenligne lange forespørgsler. Især ved at udvidelsen bruger Query Analyzer (som vil fungere for HVER forespørgsel ALVET ):
Indstilling af pg_stat_statements.max 10 gange større burde tage 10 gange mere delt hukommelse tror jeg. Udvoksningerne skal være lineære . Det står ikke i dokumentationen , men det burde logisk set være det.
Der er intet svar, om det er sikkert eller ej at indstille indstillingen til distinkt værdi, fordi der ikke er data om andre konfigurationsværdier og HW, du har. Men da væksten burde være lineær, så overvej dette svar:"hvis du indstiller den til 5K, og forespørgsels runtime er næsten intet vokset, så vil indstilling af den til 50K forlænge det næsten ingenting gange ti". BTW, mit spørgsmål - hvem vil grave 50000 langsomme udsagn? :)
2.
Denne udvidelse laver allerede en præ-aggregering for "dis-valued" erklæring. Du kan vælge det direkte på DB, så at flytte data til en anden DB og vælge den der vil kun give dig fordelen ved at fjerne den originale DB og indlæse en anden. Med andre ord sparer du 50 MB til en forespørgsel på original, men bruger det samme på en anden. Giver det mening? For mig - ja. Det er hvad jeg selv gør. Men jeg gemmer også eksekveringsplaner til sætning (som ikke er en del af pg_stat_statements-udvidelsen). Jeg tror det afhænger af hvad du har og hvad du har. Det er der bestemt ikke behov for, bare på grund af en række forespørgsler. Igen, medmindre du har så stor fil, at udvidelsen kan