public inbox for [email protected]
help / color / mirror / Atom feedFrom: Rick Otten <[email protected]>
To: Lars Aksel Opsahl <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
Date: Mon, 9 Dec 2024 09:25:45 -0500
Message-ID: <CAMAYy4J3TEMKjbs4imE1iqPNDmi2ZCRUm0aZtcsvFNRxgQLqOA@mail.gmail.com> (raw)
In-Reply-To: <AM7P189MB10281DCA1FD196A5610484B29D3C2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
References: <AM7P189MB10281DCA1FD196A5610484B29D3C2@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
>
>
> 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?
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: PostgreSQL and a Catch-22 Issue related to dead rows
In-Reply-To: <CAMAYy4J3TEMKjbs4imE1iqPNDmi2ZCRUm0aZtcsvFNRxgQLqOA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox