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
|
Список | 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 по дате отправления: