Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 8320D650F27 for ; Thu, 26 Jun 2008 10:17:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 77060-02-3 for ; Thu, 26 Jun 2008 10:17:27 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from www.postnewspapers.com.au (www.postnewspapers.com.au [202.61.230.242]) by postgresql.org (Postfix) with ESMTP id B9DAA650EE2 for ; Thu, 26 Jun 2008 10:16:29 -0300 (ADT) Received: from mail.postnewspapers.com.au (202-89-185-120.static.dsl.amnet.net.au [202.89.185.120]) by www.postnewspapers.com.au (Postfix) with ESMTP id 1181D5C0AE; Thu, 26 Jun 2008 21:16:27 +0800 (WST) Received: from localhost (access [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id DE3121E0435; Thu, 26 Jun 2008 21:16:26 +0800 (WST) X-Virus-Scanned: Debian amavisd-new at postnewspapers.com.au Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (access.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id D7HexHIIuSWo; Thu, 26 Jun 2008 21:16:26 +0800 (WST) Received: from [192.168.44.95] (203.161.97.213.static.amnet.net.au [203.161.97.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTP id 0E7421E0434; Thu, 26 Jun 2008 21:16:26 +0800 (WST) Message-ID: <486396A9.1030208@postnewspapers.com.au> Date: Thu, 26 Jun 2008 21:16:25 +0800 From: Craig Ringer User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Holger Hoffstaette Cc: pgsql-performance@postgresql.org Subject: Re: ??: Postgresql update op is very very slow References: <473587.97248.qm@web32701.mail.mud.yahoo.com> <004b01c8d671$3dec1630$0544000a@hz.ali.com> <486219B6.7050003@enterprisedb.com> <005101c8d773$ff81b2c0$0644000a@hz.ali.com> <48638939.5080500@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/165 X-Sequence-Number: 30515 Holger Hoffstaette wrote: > Hi - > > I have been following this thread and find some of the recommendations > really surprising. I understand that MVCC necessarily creates overhead, > in-place updates would not be safe against crashes etc. but have a hard > time believing that this is such a huge problem for RDBMS in 2008. How do > large databases treat mass updates? AFAIK both DB2 and Oracle use MVCC > (maybe a different kind?) as well, but I cannot believe that large updates > still pose such big problems. > Are there no options (algorithms) for adaptively choosing different > update strategies that do not incur the full MVCC overhead? I think Pg already does in place updates, or close, if the tuples being replaced aren't referenced by any in-flight transaction. I noticed a while ago that if I'm doing bulk load/update work, if there aren't any other transactions no MVCC bloat seems to occur and updates are faster. I'd be interested to have this confirmed, as I don't think I've seen it documented anywhere. Is it a side-effect/benefit of HOT somehow? -- Craig Ringer