| From: | Hannu Krosing <hannu(at)skype(dot)net> |
|---|---|
| To: | Satoshi Nagayasu <nagayasus(at)nttdata(dot)co(dot)jp> |
| Cc: | 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>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Pre-allocated free space for row |
| Date: | 2005-08-31 10:18:51 |
| Message-ID: | 1125483531.5168.16.camel@fuji.krosing.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On K, 2005-08-31 at 16:50 +0900, Satoshi Nagayasu wrote:
> Simon Riggs wrote:
> >>4. Allow to repair fragmentation in each page.
> >>
> >>Because updates cause fragmentation in the page.
> >>
> >>So we need to keep large continuous free space in each page,
> >>if we want to get more effective on PCTFREE feature.
> >
> >
> > ...doesn't VACUUM already do that?
>
> 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.
--
Hannu Krosing <hannu(at)skype(dot)net>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | prasanna mavinakuli | 2005-08-31 12:08:10 | problem with PQExecParams |
| Previous Message | William ZHANG | 2005-08-31 09:51:21 | Re: Call for 7.5 feature completion |