Re: Postgres for a "data warehouse", 5-10 TB

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <shortcutter(at)googlemail(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Postgres for a "data warehouse", 5-10 TB
Date: 2011-09-13 20:34:02
Message-ID: 4E6F77EA0200002500041137@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Robert Klemme wrote:
> On 12.09.2011 19:22, Andy Colson wrote:

>> There are transaction isolation levels, but they are like playing
>> with fire. (in my opinion).

> You make them sound like witchcraft. But they are clearly defined
> - even standardized.

Yeah, for decades. Developing concurrency control from scratch at
the application level over and over again is more like playing with
fire, in my book.

> Granted, different RDBMS might implement them in different ways -
> here's PG's view of TX isolation:

> http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html

Oh, that link is *so* day-before-yesterday! Try this one:

http://www.postgresql.org/docs/9.1/interactive/transaction-iso.html

> In my opinion anybody working with RDBMS should make himself
> familiar with this concept - at least know about it - because it
> is one of the fundamental features of RDBMS and certainly needs
> consideration in applications with highly concurrent DB activity.

+1

Understanding what levels of transaction isolation are available,
and what the implications of each are, is fundamental. Just as
there are cases where a foreign key constraint doesn't exactly work
for what you need to enforce, there are cases where serializable
transactions don't fit. But where they do fit, developing the
equivalent from scratch all over again is not as safe or productive
as using the built-in feature.

-Kevin

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2011-09-13 21:13:00 Re: Migrated from 8.3 to 9.0 - need to update config (re-post)
Previous Message Robert Klemme 2011-09-13 20:26:04 Re: Postgres for a "data warehouse", 5-10 TB