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

Поиск
Список
Период
Сортировка
От Thomas Boussekey
Тема Re: autovacuum failing on pg_largeobject and disk usage of thepg_largeobject growing unchecked
Дата
Msg-id CALUeYmebqC4DC+mbU2KZzOsLoKvgsUwCoYCpYUjq7GjtRusasg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: autovacuum failing on pg_largeobject and disk usage of the pg_largeobject growing unchecked  ("Jim Hurne" <jhurne@us.ibm.com>)
Список pgsql-general


Le mer. 24 juin 2020 à 16:24, Jim Hurne <jhurne@us.ibm.com> a écrit :
"Daniel Verite" <daniel@manitou-mail.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:

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 

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgbench and timestamps
Следующее
От: "Bee.Lists"
Дата:
Сообщение: Re: Persistent Connections