Re: configuring queries for concurrent updates

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: Robert Poor <rdpoor(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: configuring queries for concurrent updates
Date: 2012-06-24 07:06:44
Message-ID: 4FE6BC84.7030605@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 06/23/2012 02:33 PM, Robert Poor wrote:
> [std_disclaimer]I'm not a DBA and I'm running PostgreSQL on a
> quad-core Intel laptop. You may read on after you stop
> laughing...[/std_disclaimer]

Laughing?

You don't need to be a formally-qualified DBA to use Pg. That's half the
point - it's focused on safe and correct behaviour and has great
documentation so you don't need to go through an extensive training
course just to turn it on.

I run Pg on several machines, but of all of them my quad-core
SSD-equiped i7 laptop is by far the fastest. It's perfectly reasonable
to run a small Pg database on very small hardware and expect it to
perform very well.

Of course, if you're throwing millions of rows and terabytes of data
around you'll want to have hardware to match, but Pg scales down as well
as up.

> I've written a version of UPSERT designed to import a large number of
> records. It works in two steps: it UPDATEs incumbent records that
> share common keys with the new records, then INSERTs new records that
> do not share common keys with the incumbent records.

That's incorrect; it's subject to several nasty races. The best article
I've seen on this is here:

http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/

(thanks again depesz for your great articles).

--
Craig Ringer

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Poor 2012-06-24 07:42:18 Re: configuring queries for concurrent updates
Previous Message Tim Uckun 2012-06-24 06:57:27 Hot standby streaming replication doesn't work