From: | Lists <lists(at)benjamindsmith(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: vacuum vs pg_repack for clearing bloat? |
Date: | 2014-01-16 01:37:27 |
Message-ID: | 52D737D7.9010401@benjamindsmith.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 01/15/2014 04:24 PM, Tom Lane wrote:
> Lists <lists(at)benjamindsmith(dot)com> writes:
>> Our app makes extensive use of temp tables, and this causes a
>> significant amount of bloat that can often only be cleared with a manual
>> vacuum process. We're looking for a better way that doesn't involve
>> locking, we found pg_repack and pg_reorg and were wondering if anybody
>> here could weigh in on using this instead of using vacuum?
> A temp table is only accessible to the owning process, so if you're hoping
> for vacuuming of it to happen silently in background, you'll be sadly
> disappointed. The speed advantage of a temp table come exactly from not
> having to worry about concurrent access, so this isn't a tradeoff that can
> easily be adjusted.
>
> regards, tom lane
Tom,
The process(es) creating the temp tables are not persistent, so the
issue isn't trying to clean up bloat from a long running process, it's
clearing out the cruft that results from creating temp tables, loading a
bunch of data, then dropping the table, either explicitly or when the
connection is terminated. This causes PG disk usage to climb without
causing any change in pg_dump output.
I was wondering if anybody else had used either of these projects
(pg_repack or pg_reorg, though reorg seems to be unsupported) and if so,
how successful they had been.
-Ben
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-01-16 01:46:19 | Re: vacuum vs pg_repack for clearing bloat? |
Previous Message | John R Pierce | 2014-01-16 01:33:19 | Re: vacuum vs pg_repack for clearing bloat? |