From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: Is this a problem in GenericXLogFinish()? |
Date: | 2023-11-10 03:47:30 |
Message-ID: | TYAPR01MB58663DB52ED18495A5AD1338F5AEA@TYAPR01MB5866.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dear hackers,
> Next we should add some test codes. I will continue considering but please post
> anything
> If you have idea.
And I did, PSA the patch. This patch adds two parts in hash_index.sql.
In the first part, the primary bucket page is filled by live tuples and some overflow
pages are by dead ones. This leads removal of overflow pages without moving tuples.
HEAD will crash if this were executed, which is already reported on hackers.
The second one tests a case (ntups == 0 && is_prim_bucket_same_wrt == false &&
is_prev_bucket_same_wrt == true), which is never done before.
Also, I measured the execution time of before/after patching. Below is a madian
for 9 measurements.
BEFORE -> AFTER
647 ms -> 710 ms
This means that the execution time increased -10%, it will not affect so much.
How do you think?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
Attachment | Content-Type | Size |
---|---|---|
fix_hash_squeeze_wal_4.patch | application/octet-stream | 5.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-11-10 03:54:22 | AdvanceXLInsertBuffers() vs wal_sync_method=open_datasync |
Previous Message | torikoshia | 2023-11-10 03:33:50 | Re: Add new option 'all' to pg_stat_reset_shared() |