Re: Eliminating PD_ALL_VISIBLE, take 2 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Eliminating PD_ALL_VISIBLE, take 2
Date
Msg-id 1372787267.19747.124.camel@jdavis
Whole thread Raw
In response to Re: Eliminating PD_ALL_VISIBLE, take 2  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On Tue, 2013-07-02 at 19:34 +0200, Andres Freund wrote:
> Well, I still have my doubts that it's a good idea to remove this
> knowledge from the page level. And that's not primarily related to
> performance. Unfortunately a good part of judging architectural
> questions is gut feeling...
> The only real argument for the removal I see - removal of one cycle of
> dirtying - wouldn't really weigh much if we would combine it with
> freezing (which we can do if Robert's forensic freezing patch makes it
> in).

I'll have to take a closer look at the relationship between Robert's and
Heikki's proposals.

I have a gut feeling that the complexity we go through to maintain
PD_ALL_VISIBLE is unnecessary and will cause us problems later. If we
could combine freezing and marking all-visible, and use WAL for
PD_ALL_VISIBLE in a normal fashion, then I'd be content with that.

Even better would be if we could eliminate the freeze I/O with Heikki's
proposal, and eliminate the PD_ALL_VISIBLE I/O with my patch. But,
that's easier said than done.

Regards,Jeff Davis





pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Patch: clean up addRangeTableEntryForFunction
Next
From: Hannu Krosing
Date:
Subject: Re: [9.4 CF 1] The Commitfest Slacker List