Re: configuring queries for concurrent updates - Mailing list pgsql-general

From Craig Ringer
Subject Re: configuring queries for concurrent updates
Date
Msg-id 4FE6BC84.7030605@ringerc.id.au
Whole thread Raw
In response to configuring queries for concurrent updates  (Robert Poor <rdpoor@gmail.com>)
Responses Re: configuring queries for concurrent updates  (Robert Poor <rdpoor@gmail.com>)
List 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

pgsql-general by date:

Previous
From: Tim Uckun
Date:
Subject: Hot standby streaming replication doesn't work
Next
From: Robert Poor
Date:
Subject: Re: configuring queries for concurrent updates