From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: FSM rewrite committed, loose ends |
Date: | 2008-09-30 12:59:08 |
Message-ID: | 200809301459.08352.dfontaine@hi-media.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Le mardi 30 septembre 2008, Heikki Linnakangas a écrit :
> Dimitri Fontaine wrote:
> > Question for the slow readers: this new FSM scheme being dynamic, it's no
> > longer possible to have table bloat, right?
> > (where table bloat is full of dead-for-any-transaction tuples, and you
> > have to CLUSTER or VACUUM FULL to be able to reuse the space it takes)
>
> No, it didn't change that. Regular VACUUMing or autovacuum is still needed.
But IIUC correctly it's no longer possible for PostgreSQL to forget about
where bloat is, so regular vacuuming will know how clean out any bloat any
time?
For example, a purge script which does a large DELETE could overrun the
max_fsm_pages setting, resulting in permanent bloat (until table rewrite).
This large DELETE will now be tracked completely by the new FSM, so
autovacuum will be able to have the space reused later?
--
dim
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-09-30 13:04:13 | Re: FSM rewrite committed, loose ends |
Previous Message | Andrew Dunstan | 2008-09-30 12:55:47 | Re: parallel pg_restore - WIP patch |