| From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
|---|---|
| To: | Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Christophe Pettus <xof(at)thebuild(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: PostgreSQL and a Catch-22 Issue related to dead rows |
| Date: | 2024-12-10 13:03:28 |
| Message-ID: | CAKAnmmJLzTQAEzyBoLhG40WEN3siWFSBT68GSu2b_mF=WJL-JQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Dec 10, 2024 at 3:55 AM Lars Aksel Opsahl <Lars(dot)Opsahl(at)nibio(dot)no>
wrote:
> Is it difficult to add parameter like force-dead-rows-removal that we send
> to the vacuum job that will remove this rows like this ?
>
> I'm still not sure what the ask here is - complete literal removal of the
dead rows? That's not how PG works. I'm wondering if we are not in an XY
problem. Your queries are slow, and you think it's because of
autovacuum's output re dead rows. But let's take a step back and look at
the actual queries being run that are slowing down. Perhaps there are other
solutions: less indexing, more freezing, smarter updates, different
partitioning, tweaking fillfactor, etc. etc. There are lots of things we
can try that will be orders of magnitude simpler than trying to redesign
MVCC/vacuuming. :)
Cheers,
Greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Lars Aksel Opsahl | 2024-12-10 14:03:41 | Re: PostgreSQL and a Catch-22 Issue related to dead rows |
| Previous Message | David Mullineux | 2024-12-10 09:22:37 | Re: can a blocked transaction affect the performance of one that is blocking it? |