Re: Out of Memory - 8.2.4
От | Tom Lane |
---|---|
Тема | Re: Out of Memory - 8.2.4 |
Дата | |
Msg-id | 15555.1188344487@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Out of Memory - 8.2.4 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Out of Memory - 8.2.4
|
Список | pgsql-general |
Alvaro Herrera <alvherre@commandprompt.com> 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
В списке pgsql-general по дате отправления: