I've been doing more testing on several different machines, but still
haven't found a solution to my problem where VACUUM FULL is running out of
memory. Besides the original case on RHEL4, I've been able to reproduce it
on both Windows and OSX, with 3GB and 5GB RAM, respectively. Interestingly,
i
Scott Marlowe wrote:
> My usage is dictated by using slony, which means I can't do the
> things I'd like, like just copying the data out of the table,
> truncating it, and copying it back in / renaming the newly created
> table as the old one etc. So for me, and other slony users who
> can't do
On Mon, Dec 14, 2009 at 1:55 PM, Kevin Grittner
wrote:
> David Schnur wrote:
>
>> For a bit of extra context, the database is embedded within a
>> piece of software, which is the source of the uncertainty. If it
>> was something I could manage myself, I would just run the VACUUM
>> FULL by hand
David Schnur wrote:
> For a bit of extra context, the database is embedded within a
> piece of software, which is the source of the uncertainty. If it
> was something I could manage myself, I would just run the VACUUM
> FULL by hand at those times when I knew it was necessary. As it
> stands,
>
> If you actually expect it to be re-used by the database sometime
> later, I would just stick with normal VACUUM (with adequate fsm
It may or may not be used again. Although disk is cheap, it is a
substantial amount of space, and I'd prefer it wasn't locked-up forever.
For a bit of extra con
David Schnur wrote:
> Regular VACUUM is fine most of the time; it frees up space for
> re-use, the space gets re-used, and the disk size stays constant.
> But at certain non-predictable points in time, the database may
> expire several times more rows than usual, and in that case I want
> to re
On Mon, Dec 14, 2009 at 5:53 PM, David Schnur wrote:
> Is my understanding of VACUUM v.s. VACUUM FULL correct, actually? It
> appears to work that way, but the docs are a little vague on whether plain
> VACUUM ever frees actual disk space, or just reclaims it for the DB.
Basically. VACUUM does c
On Mon, Dec 14, 2009 at 12:04 PM, Kevin Grittner <
kevin.gritt...@wicourts.gov> wrote:
> I hope you've been following that with a REINDEX every time;
> otherwise you're causing index bloat.
Yes, it REINDEXes afterwards.
Are these inserts happening in the same table(s) each time? If so,
> what
David Schnur wrote:
> I have a weekly task set up to VACUUM FULL a fairly large (~300M
> row ~50GB) database.
I hope you've been following that with a REINDEX every time;
otherwise you're causing index bloat.
> The intent is to free up disk space from especially-large inserts
> that aren't c
Hello,
I have a weekly task set up to VACUUM FULL a fairly large (~300M row ~50GB)
database. The intent is to free up disk space from especially-large inserts
that aren't covered by the regular reclamation from a daily VACUUM.
Recently, I've been getting the following error:
(OperationalError)
10 matches
Mail list logo
