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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: Non-blocking vacuum full


  • From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
  • To: Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com>
  • Cc: pgsql-performance(at)postgresql(dot)org
  • Subject: Re: Non-blocking vacuum full
  • Date: Sat, 29 Sep 2007 09:05:18 +0100
  • Message-id: <46FE073E.4040003@enterprisedb.com> <text/plain>

Ron Mayer wrote:
> Heikki Linnakangas wrote:
>> Peter Schuller wrote:
>>> to have a slow background process (similar to normal non-full vacuums
>> ... 
>> I think it's doable, if you take a copy of the tuple, and set the ctid
>> pointer on the old one like an UPDATE, and wait until the old tuple is
>> no longer visible to anyone before removing it. It does require some
>> changes to tuple visibility code.
> 
> Wouldn't just having this slow background process
> repeatedly alternating between
>  update table set anycol=anycol where ctid > [some ctid near the end]
> and running normal VACUUM statements do what the original poster
> was asking? 

Almost. Updaters would block waiting for the UPDATE, and updaters in
serializable mode would throw serialization errors. And the "WHERE ctid
> ?" would actually result in a seq scan scanning the whole table, since
our tid scans don't support inequality searches.

> And with 8.3, I guess also avoiding HOT?

HOT shouldn't cause any complications here AFAICS.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group