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: | Raw Message | Whole Thread | 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 |