Re: Eliminating PD_ALL_VISIBLE, take 2

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Robins <robins(at)pobox(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Eliminating PD_ALL_VISIBLE, take 2
Date: 2013-07-02 17:47:47
Message-ID: 1372787267.19747.124.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2013-07-02 19:00:48 Re: [9.4 CF 1] The Commitfest Slacker List
Previous Message Robert Haas 2013-07-02 17:45:38 Re: Patch: clean up addRangeTableEntryForFunction