Re: [GENERAL] Autovacuum Improvements

Поиск
Список
Период
Сортировка
От Kenneth Marshall
Тема Re: [GENERAL] Autovacuum Improvements
Дата
Msg-id 20070125135920.GI27859@it.is.rice.edu
обсуждение исходный текст
Ответ на Re: [GENERAL] Autovacuum Improvements  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: NULL value in subselect in UNION causes error
Следующее
От: Sorin Schwimmer
Дата:
Сообщение: Re: New feature proposal