Re: [HACKERS] Resurrecting per-page cleaner for btree
От | Martijn van Oosterhout |
---|---|
Тема | Re: [HACKERS] Resurrecting per-page cleaner for btree |
Дата | |
Msg-id | 20060726210238.GD32377@svana.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] Resurrecting per-page cleaner for btree (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: [HACKERS] Resurrecting per-page cleaner for btree
|
Список | pgsql-patches |
On Wed, Jul 26, 2006 at 12:47:57PM -0400, Greg Stark wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > So far, the case hasn't been made for retail vacuum even ignoring the > > not-so-immutable-function risk. > > Well the desire for it comes from a very well established need for dealing > with extremely large tales with relatively small hot spots. The basic problem > being that currently the cost of vacuum is proportional to the size of the > table rather than the amount of dead space. There's no link between those > variables (at least in one direction) and any time they're far out of whack it > means excruciating pain for the DBA. I thought the suggested solution for that was the dead space map. That way vacuum can ignore parts of the table that havn't changed... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
В списке pgsql-patches по дате отправления: