MIME-Version: 1.0
References: 
 <AM7P189MB10281DCA1FD196A5610484B29D3C2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
In-Reply-To: 
 <AM7P189MB10281DCA1FD196A5610484B29D3C2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
From: Rick Otten <rottenwindfish@gmail.com>
Date: Mon, 9 Dec 2024 09:25:45 -0500
Message-ID: 
 <CAMAYy4J3TEMKjbs4imE1iqPNDmi2ZCRUm0aZtcsvFNRxgQLqOA@mail.gmail.com>
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
To: Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
Cc: "pgsql-performance@lists.postgresql.org"
 <pgsql-performance@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000084f9bf0628d7247a"
Archived-At: 
 <https://www.postgresql.org/message-id/CAMAYy4J3TEMKjbs4imE1iqPNDmi2ZCRUm0aZtcsvFNRxgQLqOA%40mail.gmail.com>
Precedence: bulk

--00000000000084f9bf0628d7247a
Content-Type: text/plain; charset="UTF-8"

>
>
> Yes there are very good reason for the way removal for dead rows work now,
> but is there any chance of adding an option when creating table to disable
> this behavior for instance for unlogged tables ?
>
>
>
Are you saying your job is I/O bound (not memory or cpu).  And that you can
only improve I/O performance by committing more frequently because the
commit removes dead tuples which you have no other means to clear?   Is
your WAL already on your fastest disk?

All of your parallel jobs are operating on the same set of rows?  So
partitioning the table wouldn't help?

--00000000000084f9bf0628d7247a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div class=3D"msg22889144884554898=
80"><div dir=3D"ltr"><div style=3D"font-family:Aptos,Aptos_EmbeddedFont,Apt=
os_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,=
0)"><br>
</div>
<div style=3D"font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Cali=
bri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Yes there are very good reason for the way removal for dead rows work now, =
but is there any chance of adding an option when creating table to disable =
this behavior for instance for unlogged tables ?</div>
<div style=3D"font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Cali=
bri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Cali=
bri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><br></div></div><=
/div></blockquote><div><br></div><div>Are you saying your job is I/O bound =
(not memory or cpu).=C2=A0 And that you can only improve I/O performance by=
 committing more frequently because the commit removes dead tuples which yo=
u have no other means to clear?=C2=A0 =C2=A0Is your WAL already on your fas=
test disk?</div><div><br></div><div>All of your parallel jobs are operating=
 on the same set of rows?=C2=A0 So partitioning the table wouldn&#39;t help=
?</div><div>=C2=A0</div></div></div>

--00000000000084f9bf0628d7247a--