David Schnur <dnschnur@gmail.com> 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, it's not predictable, and users also tend to be less
> accepting of having that space locked up.
>
> That's why I'm interested in more information on the memory & disk
> requirements of the various maintenance functions. The main
> reason I've stayed away from CLUSTER is because of the disk
> requirement. But I had no idea it was possible for VACUUM FULL to
> run out of memory under normal conditions, so I may need to
> reconsider the options.
If you had a utility which could be run when desired, which would
incrementally move data from the end of a table to free space within
the table, would that do? It could be run while the table was in
use for other purposes, but could cause occasional serialization
failures for updates -- so you might want to schedule it for
maintenance windows when possible. Unlike the current VACUUM
ANALYZE, stopping it would not lose the work done up to that point.
(The above is being considered as a replacement for the current
VACUUM FULL techniques where you don't have room for a second copy
of the table. If there's some reason that *wouldn't* work for you,
now would be a good time to weigh in.)
-Kevin
