Free space mapping (was Re: Multi-Versions and Vacuum)
От | Tom Lane |
---|---|
Тема | Free space mapping (was Re: Multi-Versions and Vacuum) |
Дата | |
Msg-id | 14168.1027102269@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Multi-Versions and Vacuum (Andrew Sullivan <andrew@libertyrms.info>) |
Ответы |
Re: Free space mapping (was Re: Multi-Versions and Vacuum)
Re: Free space mapping (was Re: Multi-Versions and Vacuum) Re: Free space mapping (was Re: Multi-Versions and Vacuum) |
Список | pgsql-general |
Andrew Sullivan <andrew@libertyrms.info> writes: > But if I understand now what you're saying, it's this: the vacuum > _does_ get everything, but if the free space map settings are too > small, the free space map doesn't know about that free space; > therefore, the space never gets re-used for future data, because as > far as the postmaster is concerened, the space isn't available. So > the tables keep growing because they have to append their data at the > end of the file (because the free space map hasn't reported any free > space). Run vacuum a few times like this, and there is a substantial > amount of unused space in the tables, where the free space map > doesn't have an entry for it. Is that right? Well, the design theory was that once you free enough space on a particular page, it *will* get into the FSM and then will be filled up. The fact that small amounts of free space don't get re-used quickly doesn't bother me a whole lot; the table size should still stabilize at some proportion of free to used space that depends on your vacuum frequency. However, if the FSM is vastly smaller than the number of actively-changing pages in your database, then that argument breaks down --- in particular, if the FSM can't even keep track of all the completely-empty pages in your database then you are going to suffer progressive leakage. I'm not sure where the problem gets bad enough to worry about, and have not had time to try to do a probabilistic analysis. If we could determine where trouble sets in, perhaps we could detect the situation and print warnings during VACUUM? Another possibility is to auto-size FSM during postmaster startup, perhaps as a fraction of the total DB size measured by "du". (But that probably doesn't work if you've been playing symlink games.) In any case we need more knowledge about appropriate FSM sizes than we have at the moment. The whole FSM concept is new in 7.2 and I'm sure it still needs refinement. Ideas welcome. regards, tom lane
В списке pgsql-general по дате отправления: