Re: [GENERAL] Autovacuum Improvements - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: [GENERAL] Autovacuum Improvements
Date
Msg-id 20070125135920.GI27859@it.is.rice.edu
Whole thread Raw
In response to Re: [GENERAL] Autovacuum Improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jan 24, 2007 at 07:30:05PM -0500, Tom Lane wrote:
> Kenneth Marshall <ktm@is.rice.edu> writes:
> > Not that I am aware of. Even extending the relation by one additional
> > block can make a big difference in performance
> 
> Do you have any evidence to back up that assertion?
> 
> It seems a bit nontrivial to me --- not the extension part exactly, but
> making sure that the space will get used promptly.  With the current
> code the backend extending a relation will do subsequent inserts into
> the block it just got, which is fine, but there's no mechanism for
> remembering that any other newly-added blocks are available --- unless
> you wanted to push them into the FSM, which could work but the current
> FSM code doesn't support piecemeal addition of space, and in any case
> there's some question in my mind about the concurrency cost of increasing
> FSM traffic even more.
> 
> In short, it's hardly an unquestionable improvement, so we need some
> evidence.
> 
>             regards, tom lane
> 

My comment was purely based on the reduction in fragmentation of the
file behind the relation. A result that I have seen repeatedly in file
related data processing. It does sound much more complicated to make the
additional space available to other backends. If one backend was doing
many inserts, it might still be of value even for just that backend. As
you mention, testing is needed to see if there is enough value in this
process.

Ken



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: NULL value in subselect in UNION causes error
Next
From: Sorin Schwimmer
Date:
Subject: Re: New feature proposal