Re: Set visibility map bit after HOT prune

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Set visibility map bit after HOT prune
Date: 2012-12-19 18:52:30
Message-ID: 19868.1355943150@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Wed, Dec 19, 2012 at 9:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If we start generating a lot of useless WAL activity and I/O as
>> a result of thrashing the all-visible bit, it won't be so tolerable
>> anymore.

> What if we wrap that into the WAL generated by HOT prune itself ?

What WAL? The case we're worried about here is that there's nothing
else for HOT prune to do.

>> I think my core point still stands: the way that HOT pruning is done now
>> is an artifact of having wanted to shoehorn it into the system with
>> minimum changes. Which was reasonable at the time given the
>> experimental status of the feature, but now it's time to reconsider.

> ISTM that you already have concret ideas about what are those places
> where HOT prune would be more effective.

No, I don't; I'm just suggesting that we ought to think outside the box
of the way it's being done now.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-12-19 18:58:37 Re: Review of Row Level Security
Previous Message Tom Lane 2012-12-19 18:47:15 Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1