Skip site navigation (1) Skip section navigation (2)

Re: Pre-allocated free space for row

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)skype(dot)net>
Cc: Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp>,Simon Riggs <simon(at)2ndquadrant(dot)com>, josh(at)agliodbs(dot)com,pgsql-hackers(at)postgresql(dot)org, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Subject: Re: Pre-allocated free space for row
Date: 2005-08-31 14:33:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hannu Krosing <hannu(at)skype(dot)net> writes:
> On K, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
>> VACUUM generates a huge load because it repaires all pages
>> on the table file.
>> I think (more light-weight) repairing on a single page
>> is needed to maintain free space in the specific page.

> There have been plans floating around for adding a more lightweight
> vacuum, which uses something similar to FSM to keep track of pages which
> need vacuuming. And possibly integreated with background writer to make
> effective use of I/O resources.

> I guess it could be used for this case of "cheap page cleanups" as well.

Pretty much all of these ideas fall down when you remember that you have
to fix indexes too.  There's no such thing as a "cheap page cleanup",
except maybe in a table with no indexes.  Cleaning out the indexes
efficiently requires a certain amount of batch processing, which leads
straight back to VACUUM.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Devrim GUNDUZDate: 2005-08-31 14:54:06
Subject: Re: problems installing pgsql
Previous:From: Andrew DunstanDate: 2005-08-31 14:24:33
Subject: Re: Call for 7.5 feature completion

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group