Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51909=pgsql-performance-ar@postgresql.org>)
 id 1X2Pzk-0003tY-2f
 for pgsql-performance@arkaria.postgresql.org; Wed, 02 Jul 2014 19:15:04 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51909=pgsql-performance-ar@postgresql.org>)
 id 1X2Pzj-00035F-H9
 for pgsql-performance@arkaria.postgresql.org; Wed, 02 Jul 2014 19:15:03 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1X2Pzi-00033G-7e
 for pgsql-performance@postgresql.org; Wed, 02 Jul 2014 19:15:02 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
 by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256)
 (Exim 4.80) (envelope-from <tgl@sss.pgh.pa.us>) id 1X2Pzf-0003r6-9b
 for pgsql-performance@postgresql.org; Wed, 02 Jul 2014 19:15:01 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
 by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id s62JEqlM019808;
 Wed, 2 Jul 2014 15:14:52 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@2ndquadrant.com>
cc: Jeff Frost <jeff@pgexperts.com>,
 Matheus de Oliveira <matioli.matheus@gmail.com>,
 Soni M <diptatapa@gmail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>,
 pgsql-performance <pgsql-performance@postgresql.org>
Subject: Re: Postgres Replaying WAL slowly
In-reply-to: <20140702190111.GC25909@awork2.anarazel.de>
References: <B22B06CF-2BC0-4AB6-8E3C-FACDF8193F23@pgexperts.com>
 <20140630201523.GV26930@awork2.anarazel.de>
 <943ECC8E-8899-422E-937C-50DE20E1F7AC@pgexperts.com>
 <21474.1404160784@sss.pgh.pa.us>
 <2E438E7D-E3C1-47A1-A1AF-9FE50A14A302@pgexperts.com>
 <571D044B-260A-4E06-ACBC-8869B8F73C0F@pgexperts.com>
 <24455.1404169460@sss.pgh.pa.us>
 <BB7C727F-201D-4CA7-AB00-8EDF6EBFD04B@pgexperts.com>
 <608DF51D-AEFB-422B-AD2C-ABA9A114AA27@pgexperts.com>
 <18433.1404242437@sss.pgh.pa.us> <20140702190111.GC25909@awork2.anarazel.de>
Comments: In-reply-to Andres Freund <andres@2ndquadrant.com>
 message dated "Wed, 02 Jul 2014 21:01:11 +0200"
Date: Wed, 02 Jul 2014 15:14:52 -0400
Message-ID: <19807.1404328492@sss.pgh.pa.us>
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-07-01 15:20:37 -0400, Tom Lane wrote:
>> It seems like there are three, not mutually exclusive, ways we might
>> address this:

> But I think more importantly it's probably quite possible to hit a
> similar problem without ON COMMIT DROP relations. Say DISCARD TEMP
> inside a transaction (with several subxacts) or so? So we probaly really
> should fix the bad scaling.

Well, my thought was that these approaches would address somewhat
different sets of use-cases, and we might well want to do more than one.
Even if StandbyReleaseLocks were zero-cost, not emitting the WAL in the
first place is surely considerably cheaper yet.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance