Skip site navigation (1) Skip section navigation (2)

Re: Automatic free space map filling

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatic free space map filling
Date: 2006-02-28 22:10:52
Message-ID: 1141164653.5106.15.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Ühel kenal päeval, E, 2006-02-27 kell 19:20, kirjutas Peter Eisentraut:
> Something came to my mind today, I'm not sure if it's feasible but I 
> would like to know opinions on it.
> We've seen database applications that PostgreSQL simply could not manage 
> because one would have to vacuum continuously.

What's wrong with vacuuminng continuously ?

I am running an application, that in fact does vacuum continuously
without any ill effects. A case when things become compliacted, is when
you have one huge table (say 50.000.000 rows) that is updated at a
moderate rate and needs an occasional vacuum + a fast-update table,
which needs continuous vacuum. Due to current implementation of vacuum,
you have to abandon continuous vacuuming during vacuum of bigtable, but
i have written and submitted to "patches" list a patch which allows
vacuums not to block each other out, this is stalled due to Tom's
"unesyness" about its possible hidden effects, but it should be
available from "patches" list to anyone in distress :p

>   Perhaps in those 
> situations one could arrange it that an update (or delete) of a row 
> registers the space in the free space map right away, on the assumption 
> that by the time it is up for reuse, the transaction will likely have 
> committed.  Naturally, this would need to be secured in some way, for 
> example a "maybe" bit in the FSM itself or simply checking that the 
> supposed free space is really free before using it, perhaps combined 
> with a timeout ("don't consider until 5 seconds from now").

Unfortunately transactions have no knowledge about wallclock time :(

> I think with applications that have a more or less constant data volume 


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-02-28 22:29:08
Subject: Re: bug in PG_VERSION_NUM patch
Previous:From: Bruce MomjianDate: 2006-02-28 21:58:21
Subject: Re: bug in PG_VERSION_NUM patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group