Re: VACUUM FULL pg_largeobject without (much) downtime?

From: Adam Hooper <adam(at)adamhooper(dot)com>
To: Bill Moran <wmoran(at)potentialtech(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: VACUUM FULL pg_largeobject without (much) downtime?
Date: 2015-02-04 21:26:06
Message-ID: CAMWjz6G2XCVN8EEJD=Vbea-9HoL2km0Dxy5BFgbfn70Mak2gXQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Feb 3, 2015 at 3:12 PM, Bill Moran <wmoran(at)potentialtech(dot)com> wrote:
> On Tue, 3 Feb 2015 14:48:17 -0500
> Adam Hooper <adam(at)adamhooper(dot)com> wrote:
>
>> It's doable for us to VACUUM FULL and add a notice to our website
>> saying, "you can't upload files for the next two hours." Maybe that's
>> a better idea?
>
> It's really going to depend on what options you have available. Keep
> in mind that users won't be able to read large objects either, so
> you'll need to disable whatever features of the site view the files
> as well. Whether that's easier or harder depends on how much work it
> would be to disable those features of the site.

For the record, this is what we went with.

To those looking to use large objects (who, um, are already searching
for how to VACUUM FULL pg_largeobject), my advice: if we were to do it
all over again, we'd have used a separate database per "bucket".

For instance, imagine you store uploaded files and processed data in
pg_largeobject. Then some day you migrate the processed data
elsewhere. If uploaded files went in one database and processed data
went into the second, then the uploaded-files database's
pg_largeobject table would remain slim, and you could simply DROP
DATABASE on the other after all clients stopped using it. There
wouldn't be any downtime.

My take-away, though, is to avoid the pg_largeobject table whenever
possible. You can move BYTEA data with zero downtime using pg_repack,
but the same can't be said for large objects.

Enjoy life,
Adam

--
Adam Hooper
+1-613-986-3339
http://adamhooper.com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Elijah Zupancic 2015-02-05 00:08:07 pg_dump search path issue
Previous Message Paul Jungwirth 2015-02-04 20:40:36 Re: How do I bump a row to the front of sort efficiently