Re: Plans for solving the VACUUM problem
От | Tom Lane |
---|---|
Тема | Re: Plans for solving the VACUUM problem |
Дата | |
Msg-id | 13738.990162169@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | RE: Plans for solving the VACUUM problem (Mike Mascari <mascarm@mascari.com>) |
Список | pgsql-hackers |
Mike Mascari <mascarm@mascari.com> writes: > Very neat. You mention that the truncation of both heap and index > relations is not necessarily mandatory. Under what conditions would > either of them be truncated? In the proposal as given, a heap file would be truncated if (a) it has at least one totally empty block at the end, and (b) no other transaction is touching the table at the instant that VACUUM is ready to truncate it. This would probably be fairly infrequently true, especially for heavily used tables, but if you believe in a "steady state" analysis then that's just fine. No point in handing blocks back to the OS only to have to allocate them again soon. We might want to try to tilt the FSM-driven reuse of freed space to favor space near the start of the file and avoid end blocks. Without that, you might never get totally free blocks at the end. The same comments hold for index blocks, with the additional problem that the index structure would make it almost impossible to drive usage away from the physical end-of-file. For btrees I think it'd be sufficient if we could recycle empty blocks for use elsewhere in the btree structure. Actually shrinking the index probably won't happen short of a REINDEX. regards, tom lane
В списке pgsql-hackers по дате отправления: