| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Martín Fernández <fmartin91(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Logical Replication and table bloat |
| Date: | 2020-06-05 20:54:12 |
| Message-ID: | 4e349fe4-fc9e-f988-de10-ecf9d18664ab@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 2020-06-05 21:53, Martín Fernández wrote:
> Yesterday we stumbled upon a performance issue that we were not expecting. We are replicating our database using AWS DMS which uses logical replication to capture changes. We have some hot tables that get updated very regularly and with the DMS turned on we started noticing that in those table, table bloat increased considerably ~15 times more free_tuples than the average.
>
> When doing logical replication, the subscriber will hold the tuples that could be flagged for reuse until they are sent ? Just trying to understand a little bit better how the logical replication is affecting the vacuuming.
As far as vacuum is concerned, it is very similar to a normal client
session: It may insert tuples, update tuples, delete tuples; update and
delete create bloat, autovacuum should come along to clean up. There
isn't normally any separate vacuum tuning necessary for this, but if you
are experiencing issues, first treat it like a normal vacuum
configuration problem.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleš Zelený | 2020-06-05 20:57:46 | Logical replication - ERROR: could not send data to WAL stream: cannot allocate memory for input buffer |
| Previous Message | Adrian Klaver | 2020-06-05 19:59:52 | Re: Logical Replication and table bloat |