Message-ID: <e3071cfc-7a9e-4476-81fd-8ff1095baabd@tantorlabs.com>
Date: Tue, 21 Jan 2025 18:46:41 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_stat_statements: improve loading and saving routines for the
 dump file
To: m.litsarev@postgrespro.ru
Cc: pgsql-hackers@lists.postgresql.org
References: <192f7185defa370d083e3a237727b066@postgrespro.ru>
 <63fd7f0d-2d49-4952-b1ec-fa877bbf0765@tantorlabs.com>
 <181d7759a2ed7d819add4e0086e7a7f9@postgrespro.ru>
Content-Language: en-US
From: Ivan Kush <ivan.kush@tantorlabs.com>
Organization: Tantor Labs LLC
In-Reply-To: <181d7759a2ed7d819add4e0086e7a7f9@postgrespro.ru>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/e3071cfc-7a9e-4476-81fd-8ff1095baabd%40tantorlabs.com>
Precedence: bulk

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.litsarev@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 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 bytes in the dump file). Once they does not coinside 
> (when the file is being read) the statistics are not loaded from the 
> dump file and set to zero and the irrelevant dump file is skipped. 
> This is the actual behaviour implemented in the code.
>
> Respectfully,
>
> Mikhail Litsarev,
> Postgres Professional: https://postgrespro.com

-- 
Best wishes,
Ivan Kush
Tantor Labs LLC