From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Subject: | Re: pg_logical_slot_get_changes waits continously for a partial WAL record spanning across 2 pages |
Date: | 2025-07-12 01:29:42 |
Message-ID: | aHG6hirCur29wzya@paquier.xyz |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 30, 2025 at 01:21:24PM +0530, Dilip Kumar wrote:
> On Fri, Jun 27, 2025 at 9:29 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>> The test execution times are measured in microseconds. In the results
>> table below, the first row indicates the message size, and each value
>> represents the median of 5 test runs.
>> The attached script was used to run these tests. In the attached
>> script the MSG_SIZE variable in the script should be changed to 1000(1
>> page), 10000 (2 pages approx), 25000 (3 pages approx) , 50000 (6 pages
>> approx), 100000 (12 page approx), 1000000 (122 pages approx), 10000000
>> (1220 pages approx) and 100000000 (12207 pages approx) and be run.
>> Test execution time can be taken from run_*.dat files that will be
>> generated.
>>
>> Size | 1000 | 10000 | 25000 | 50000 | 100000 | 1000000
>> --------|-----------|-----------|------------|-------------|------------|--------------
>> Head | 9297.1 | 9895.4 | 10844.2 | 12946.5 | 16945.1 | 86187.1
>> Patch | 9222.7 | 9889 | 10897.1 | 12904.2 | 16858.4 | 87115.5
>>
>> Size | 10000000 | 100000000
>> ---------|----------------|-----------------
>> HEAD | 804965.6 | 331639.7
>> Patch | 804942.6 | 321198.6
>>
>> The performance results show that the patch does not introduce any
>> noticeable overhead across varying message sizes, I felt there was no
>> impact because of the additional page header read.
That's encouraging, yes, thanks for these numbers. I'll try to get
some numbers myself next week. One thing that really stresses me with
this patch is that we have to do this additional header check even in
the physical replication path, but as we're just adding that for the
case where a record needs to reconstructed across two pages, perhaps
I'm just worrying too much.
> Yeah, that doesn't seem like a regression.
Yep.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-07-12 03:23:07 | Re: Missing NULL check after calling ecpg_strdup |
Previous Message | Michael Paquier | 2025-07-12 01:18:50 | Re: Can can I make an injection point wait occur no more than once? |