Hi!
Thank you for detailed explanations.
Respectfully,
Mikhail Litsarev,
Postgres Professional: https://postgrespro.com
m.litsa...@postgrespro.ru writes:
>> 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.
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
$P
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.
Regards,
Sami
What does this patch give on aglobal scale? Does it save much memory or
increase performance? How many times?
On 1/21/25 13:51, m.litsa...@postgrespro.ru wrote:
// Mutex should be last field, as this field isn't copied to dump file
Updated.
2) You didn't take into account the upgrade. Saved i
// Mutex should be last field, as this field isn't copied to dump file
Updated.
2) You didn't take into account the upgrade. Saved in Postgres with
this byte and try to load in version without this byte.
The PGSS_DUMP_FILE format is defined by PGSS_FILE_HEADER magic number
(the first four byte
Hello, Mikhail.
1) I'd add to comment a reason, why mutex should be last.
// Mutex should be last field, as this field isn't copied to dump file
+ /* protects the counters only. Should be the very last field, as this
field isn't copied to dump file
+ slock_t mutex;
} pgssE
