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: | 2007-09-29 08:05:18 |
Message-ID: | 46FE073E.4040003@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Koczan | 2007-10-01 19:23:02 | Re: sequence query performance issues |
Previous Message | Ron Mayer | 2007-09-29 02:46:28 | Re: Non-blocking vacuum full |