From: Greg Smith <gsmith@gregsmith.com>
To: Holger Hoffstaette <holger@wizards.de>
Cc: pgsql-performance@postgresql.org
Subject: Re: ??: Postgresql update op is very very slow
Date: Thu, 26 Jun 2008 18:15:14 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0806261758340.22988@westnet.com> (raw)
In-Reply-To: <pan.2008.06.26.12.40.59.151500@wizards.de>
References: <473587.97248.qm@web32701.mail.mud.yahoo.com>
<op.uc83c7m2cigqcu@apollo13.peufeu.com>
<004b01c8d671$3dec1630$0544000a@hz.ali.com>
<486219B6.7050003@enterprisedb.com>
<005101c8d773$ff81b2c0$0644000a@hz.ali.com>
<48638939.5080500@enterprisedb.com>
<pan.2008.06.26.12.40.59.151500@wizards.de>
On Thu, 26 Jun 2008, Holger Hoffstaette wrote:
> How do large databases treat mass updates? AFAIK both DB2 and Oracle use
> MVCC (maybe a different kind?) as well
An intro to the other approaches used by Oracle and DB2 (not MVCC) is at
http://wiki.postgresql.org/wiki/Why_PostgreSQL_Instead_of_MySQL:_Comparing_Reliability_and_Speed_in_...
(a URL which I really need to shorten one day).
> Are there no options (algorithms) for adaptively choosing different
> update strategies that do not incur the full MVCC overhead?
If you stare at the big picture of PostgreSQL's design, you might notice
that it usually aims to do things one way and get that implementation
right for the database's intended audience. That intended audience cares
about data integrity and correctness and is willing to suffer the overhead
that goes along with operating that way. There's few "I don't care about
reliability here so long as it's fast" switches you can flip, and not
having duplicate code paths to support them helps keep the code simpler
and therefore more reliable.
This whole area is one of those good/fast/cheap trios. If you want good
transaction guarantees on updates, you either get the hardware and
settings right to handle that (!cheap), or it's slow. The idea of
providing a !good/fast/cheap option for updates might have some
theoretical value, but I think you'd find it hard to get enough support
for that idea to get work done on it compared to the other things
developer time is being spent on right now.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: gsmith@gregsmith.com, holger@wizards.de
Subject: Re: ??: Postgresql update op is very very slow
In-Reply-To: <Pine.GSO.4.64.0806261758340.22988@westnet.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox