Re: COPY Fillfactor patch
От | Simon Riggs |
---|---|
Тема | Re: COPY Fillfactor patch |
Дата | |
Msg-id | 1114013155.16721.2275.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: COPY Fillfactor patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
On Wed, 2005-04-20 at 09:42 -0400, Tom Lane wrote: > Simon Riggs <simon@2ndquadrant.com> writes: > > On Wed, 2005-04-20 at 09:03 -0400, Bruce Momjian wrote: > >> My guess is that the FILLFACTOR will actually be a GUC variable rather > >> than a clause to CREATE INDEX or REINDEX or CLUSTER. > > > I hope not, but it would be easier to set like that and a lot easier to > > code up that way. > > I don't like that either. It seems highly unlikely that every table in > a database would need the same fillfactor. It should be a per-table > attribute, maybe with a DB-wide default, much like we handle per-column > statistics targets. > > My thought about this is that the case where extra free space really > helps is UPDATE: if heap_update can put the new tuple version on the > same page where the old one is, there's a noticeable savings. So what > you'd probably want is that heap_insert respects fillfactor (ie, won't > eat the last fillfactor percent of a page) but heap_update doesn't, > if it can thereby put the update on the same page. As long as you > vacuum before a particular page is entirely filled by updates of its > own tuples, you have a steady-state situation. Agreed. Thats the best approach. Best Regards, Simon Riggs
В списке pgsql-patches по дате отправления: