David Schnur <dnschnur@xxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
