Re: [GENERAL] Autovacuum Improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kenneth Marshall <ktm(at)is(dot)rice(dot)edu>
Cc: Jim Nasby <jim(at)nasby(dot)net>, Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [GENERAL] Autovacuum Improvements
Date: 2007-01-25 00:30:05
Message-ID: 12258.1169685005@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Kenneth Marshall <ktm(at)is(dot)rice(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Rich Shepard 2007-01-25 01:09:28 Re: Cannot Restart PostgreSQL-8.1.4
Previous Message Adam Rich 2007-01-25 00:04:39 Re: column insert/alter got me stumped!

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeremy Drake 2007-01-25 00:37:43 Re: [HACKERS] unprivileged contrib and pl install
Previous Message Tom Lane 2007-01-25 00:20:00 Re: [HACKERS] unprivileged contrib and pl install (formerly tsearch