Re: Plans for solving the VACUUM problem
От | Tim Allen |
---|---|
Тема | Re: Plans for solving the VACUUM problem |
Дата | |
Msg-id | Pine.LNX.4.21.0105181446480.14776-100000@bee.proximity.com.au обсуждение исходный текст |
Ответ на | Plans for solving the VACUUM problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 17 May 2001, Tom Lane wrote: > I have been thinking about the problem of VACUUM and how we might fix it > for 7.2. Vadim has suggested that we should attack this by implementing > an overwriting storage manager and transaction UNDO, but I'm not totally > comfortable with that approach: it seems to me that it's an awfully large > change in the way Postgres works. Instead, here is a sketch of an attack > that I think fits better into the existing system structure. <snip> > My AUD0.02, FWIW, is this sounds great. You said you were only planning to concentrate on performance enhancements, not new features, Tom, but IMHO this is a new feature and a good one :). As several others have mentioned, automatic analyze would also be nice. I gather the backend already has the ability to treat analyze as a separate process, so presumably this is a completely separate issue from automatic vacuum. Some sort of background daemon or whatever would be good. And again, one could take the approach that it doesn't have to get it 100% right, at least in the short term; as long as it is continually incrementing itself in the direction of accurate statistics, then that's much better than the current situation. Presumably one could also retain the option of doing an explicit analyze occasionally, if you have processor cycles to burn and are really keen to get the stats correct in a hurry. Tim -- ----------------------------------------------- Tim Allen tim@proximity.com.au Proximity Pty Ltd http://www.proximity.com.au/ http://www4.tpg.com.au/users/rita_tim/
В списке pgsql-hackers по дате отправления: