Re: configuring queries for concurrent updates

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: configuring queries for concurrent updates
Дата
Msg-id 4FE6BC84.7030605@ringerc.id.au
обсуждение исходный текст
Ответ на configuring queries for concurrent updates  (Robert Poor <rdpoor@gmail.com>)
Ответы Re: configuring queries for concurrent updates  (Robert Poor <rdpoor@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tim Uckun
Дата:
Сообщение: Hot standby streaming replication doesn't work
Следующее
От: Robert Poor
Дата:
Сообщение: Re: configuring queries for concurrent updates