Re: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked

From: Thomas Boussekey <thomas(dot)boussekey(at)gmail(dot)com>
To: Jim Hurne <jhurne(at)us(dot)ibm(dot)com>
Cc: Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked
Date: 2020-06-24 15:57:14
Message-ID: CALUeYmebqC4DC+mbU2KZzOsLoKvgsUwCoYCpYUjq7GjtRusasg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Le mer. 24 juin 2020 à 16:24, Jim Hurne <jhurne(at)us(dot)ibm(dot)com> a écrit :

> "Daniel Verite" <daniel(at)manitou-mail(dot)org> wrote on 06/24/2020 10:08:27 AM:
> > Unfortunately it [pg_repack] can't work with pg_largeobject
>
> That is unfortunate, and potentially leaves us in a difficult spot.
>
> Is it possible to configure PosgreSQL to use a user table for large
> objects instead of a system table?
>
> We're finding it to be especially difficult to maintain the pg_largeobject
> system table (tweak autovacuum settings, manually cleanup with something
> like pg_repack, etc), particularly since our PosrgreSQL instances are
> hosted and controlled by another team.
>
> You can consider moving your largeobjects to BYTEA storage type.
Data will be stored into user's tables (and can be split into multiple
tables, in order to to ease functionnal split and maintenance tasks -- if
needed.
Data acces is slightly different.

In the following link, you have a comparison grid:
https://www.microolap.com/products/connectivity/postgresdac/help/tipsandtricks_byteavsoid.htm

And you also have this article
https://blog-postgresql.verite.pro/2017/11/15/large-objects-bytea.html from
Daniel Vérité, in French

Regards,
>
> Jim Hurne
>
>
>
>
Regards,
Thomas

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bee.Lists 2020-06-24 17:45:21 Re: Persistent Connections
Previous Message Tom Lane 2020-06-24 15:17:20 Re: pgbench and timestamps