| 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: | 1722.1125498795@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Devrim GUNDUZ | 2005-08-31 14:54:06 | Re: problems installing pgsql |
| Previous Message | Andrew Dunstan | 2005-08-31 14:24:33 | Re: Call for 7.5 feature completion |