Re: reserving space in a rec for future update

Поиск
Список
Период
Сортировка
От Andrew Sullivan
Тема Re: reserving space in a rec for future update
Дата
Msg-id 20071114161257.GR16041@crankycanuck.ca
обсуждение исходный текст
Ответ на reserving space in a rec for future update  ("Gauthier, Dave" <dave.gauthier@intel.com>)
Ответы Re: reserving space in a rec for future update  ("Gauthier, Dave" <dave.gauthier@intel.com>)
Re: reserving space in a rec for future update  (Mike Charnoky <noky@nextbus.com>)
Список pgsql-general
On Wed, Nov 14, 2007 at 10:28:30AM -0500, Gauthier, Dave wrote:
> null.   My concern has to do with record fragmentation at the time of
> update because there's no room to "expand" them to accept the non-null
> data.  (BTW, the columns are floating point).

You have a mistaken idea about how this works.

> Is there a way to initially insert nulls, but reserve space for the
> future update (and avoid record fragmentation)?

No.

> Is my record fragmentation concern unfounded?

Sort of.

The way this will work in Postgres is that, when you UPDATE the row, the old
row will be marked dead, and a _new_ row will be written out with the new
data.  You will need to perform VACUUM in order to keep the table from
bloating.  You'll want to read the manual carefully about this topic, in
order to keep your table from getting so bloated that your free space map
becomes useless.  One of the weakest areas for PostgreSQL is its behaviour
under this sort of "most rows updated" scenario, and it is wise to plan
carefully how you will accomplish these sorts of activities without causing
yourself extreme pain.

A

--
Andrew Sullivan
Old sigs will return after re-constitution of blue smoke

В списке pgsql-general по дате отправления:

Предыдущее
От: "Scott Marlowe"
Дата:
Сообщение: Re: reserving space in a rec for future update
Следующее
От: "Jan de Visser"
Дата:
Сообщение: Re: Using generate_series to create a unique ID in a query?