Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> writes: > Marko Kreen escribió: >> I've experienced something similar. The reason turned out to be >> combination of overcommit=off, big maint_mem and several parallel >> vacuums for fast-changing tables. Seems like VACUUM allocates >> full maint_mem before start, whatever the actual size of the table. > Hmm. Maybe we should have VACUUM estimate how much is the maximum > amount of memory that would be used, given the size of the table, and > allocate only that much. Yeah --- given the likelihood of parallel vacuum activity in 8.3, it'd be good to not expend memory we certainly aren't going to need. We could set a hard limit at RelationGetNumberOfBlocks * MaxHeapTuplesPerPage TIDs, but that is *extremely* conservative (it'd work out to allocating about a quarter of the table's actual size in bytes, if I did the math right). Given that the worst-case consequence is extra index vacuum passes, which don't hurt that much when a table is small, maybe some smaller estimate like 100 TIDs per page would be enough. Or, instead of using a hard-wired constant, look at pg_class.reltuples/relpages to estimate the average tuple density ... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
