| From: | m(dot)litsarev(at)postgrespro(dot)ru |
|---|---|
| To: | Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com>, samimseih(at)gmail(dot)com |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: pg_stat_statements: improve loading and saving routines for the dump file |
| Date: | 2025-01-22 13:54:40 |
| Message-ID: | 0231a188cf457095458ba9759ac21ea1@postgrespro.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> What does this patch give on aglobal scale? Does it save much memory or
> increase performance? How many times?
This patch makes the code semantically more correct and we don't lose
anything. It is obviously not about performance or memory optimisation.
> This will only reduce the size of the
> $PGDATA/pg_stat/pg_stat_statements.txt file. Even with
> 100k entries, the most I have seen pg_stat_statements.max
> set to, that will be less than 1 MB of disk saving. The default
> config of 5k entries will be much less.
Perfectly agree. I would just add that statistics are dropped into the
pg_stat_statements.txt file at server stop which is not a very frequent
event.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shubham Khanna | 2025-01-22 13:59:09 | Enhance 'pg_createsubscriber' to retrieve databases automatically when no database is provided. |
| Previous Message | Peter Eisentraut | 2025-01-22 13:52:19 | Re: Pgoutput not capturing the generated columns |