| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: FSM, now without WAL-logging |
| Date: | 2008-09-24 17:30:43 |
| Message-ID: | 48DA7943.4000102@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Zdenek Kotala wrote:
> Heikki Linnakangas napsal(a):
>
>> It would be
>> simple to update the FSM at every heap insert and update record, but
>> that then might be an unacceptable amount of overhead at recovery. Also,
>> the index FSM is not yet updated during recovery.
>
> I expect locking problems specially on small tables where FSM has only one level
> instead slower recovery. Maybe background writer could update FSM info, but it
> breaks modularity and It could bring problems during checkpoints.
Recovery is single-threaded (for the lack of a better word) anyway, so
there can't be other backends competing for the locks. Background writer
is one option.
One option is to update the FSM if there's less than X% of free space on
the page left after the insert/update. That would be similar to the rule
we use during normal operation, which is to update the FSM whenever the
target page fills up and we have to get a new page from the FSM.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2008-09-24 18:38:36 | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |
| Previous Message | Heikki Linnakangas | 2008-09-24 17:24:59 | Re: FSM, now without WAL-logging |