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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
