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

Re: Commits 8de72b and 5457a1 (COPY FREEZE)

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>,Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Commits 8de72b and 5457a1 (COPY FREEZE)
Date: 2012-12-11 15:21:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Dec 10, 2012 at 08:04:55PM -0500, Robert Haas wrote:
> You know, I hadn't been taking that option terribly seriously, but
> maybe we ought to reconsider it.  It would certainly be simpler, and
> as you point out, it's not really any worse from an MVCC point of view
> than anything else we do.  Moreover, it would make this available to
> clients like pg_dump without further hackery.
> I think the current behavior, where we treat FREEZE as a hint, is just
> awful.  Regardless of whether the behavior is automatic or manually
> requested, the idea that you might get the optimization or not
> depending on the timing of relcache flushes seems very much
> undesirable.  I mean, if the optimization is actually important for
> performance, then you want to get it when you ask for it.  If it
> isn't, then why bother having it at all?  Let's say that COPY FREEZE
> normally doubles performance on a data load that therefore takes 8
> hours - somebody who suddenly loses that benefit because of a relcache
> flush that they can't prevent or control and ends up with a 16 hour
> data load is going to pop a gasket.

Why was this patch applied when there are obviously so many concerns
about its behavior?  Was that not clear at commit time?

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-12-11 15:21:47
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous:From: Simon RiggsDate: 2012-12-11 15:09:05
Subject: Re: allowing multiple PQclear() calls

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group