Andrew Sullivan <[EMAIL PROTECTED]> writes:
> On Thu, Aug 30, 2007 at 03:32:40PM -0400, Tom Lane wrote:
>> difference is that SERIALIZABLE takes one snapshot at transaction start
>> and works with that for the whole transaction, whereas READ COMMITTED
>> takes a new snap for each statement.
> Oh,
On Thu, Aug 30, 2007 at 03:32:40PM -0400, Tom Lane wrote:
> difference is that SERIALIZABLE takes one snapshot at transaction start
> and works with that for the whole transaction, whereas READ COMMITTED
> takes a new snap for each statement.
Oh, I get it. This explains then why in principle READ
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> I had the impression that, when working in READ COMMITTED mode, you
> could see (for instance) _new_ rows that were INSERTed by others who
> were also doing work. In SERIALIZABLE, you couldn't. So in cases
> where the additional rows met criteria in y
On Thu, Aug 30, 2007 at 02:21:56PM -0400, Tom Lane wrote:
> SERIALIZABLE mode does not introduce any waits that wouldn't happen
> anyway. It only affects what happens after you stop waiting.
Ok, this makes me think I'm deeply confused about something. (Uh,
well, on this specific topic. Anyone
Andrew Sullivan <[EMAIL PROTECTED]> writes:
> I think there's a reason why SERIALIZABLE could be slower, and that
> is that it's waiting on possibly-conflicting (but not actually
> conflicting) commits to happen in READ COMMITTED mode. No? Won't it
> have to check those things when it COMMITs?
S
On Wed, Aug 29, 2007 at 10:22:32PM +0100, Gregory Stark wrote:
> mode. In fact I believe SERIALIZABLE mode is actually measurably faster in
> benchmarks but haven't run one in READ COMMITTED mode recently (for that
> reason).
I think there's a reason why SERIALIZABLE could be slower, and that
is t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gregory Stark wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>
>> Tom Lane wrote:
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> SERIALIZABLE is really slow :).
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> Tom Lane wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> SERIALIZABLE is really slow :).
Say what? If anything it's probably faster than READ COMMITTED, becaus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
SERIALIZABLE is really slow :).
>>> Say what? If anything it's probably faster than READ COMMITTED, because
>>> i
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>>> SERIALIZABLE is really slow :).
>>
>> Say what? If anything it's probably faster than READ COMMITTED, because
>> it doesn't take as many snapshots. But the difference is likely do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> "Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Ron Johnson wrote:
>>> Argh!!! The RDBMS that I typically use defaults to SERIALIZABLE.
>
>> SERIALIZABLE is really slow :).
>
> Say what? If anything it's probably faster than READ
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> Ron Johnson wrote:
>> Argh!!! The RDBMS that I typically use defaults to SERIALIZABLE.
> SERIALIZABLE is really slow :).
Say what? If anything it's probably faster than READ COMMITTED, because
it doesn't take as many snapshots. But the difference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/29/07 10:47, Tom Lane wrote:
> Ron Johnson <[EMAIL PROTECTED]> writes:
>> On 08/29/07 07:27, cluster wrote:
>>> Just make sure and read up about transaction isolation... in the default
>>> of READ COMMITTED mode, you can sometimes see changes mad
Ron Johnson <[EMAIL PROTECTED]> writes:
> On 08/29/07 07:27, cluster wrote:
>> Just make sure and read up about transaction isolation... in the default
>> of READ COMMITTED mode, you can sometimes see changes made by other
>> transactions.
> Argh!!! The RDBMS that I typically use defaults to SERI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ron Johnson wrote:
> On 08/29/07 09:34, Decibel! wrote:
>> On Wed, Aug 29, 2007 at 08:37:26AM -0500, Ron Johnson wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 08/29/07 07:27, cluster wrote:
OK, thanks. But what with the s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/29/07 09:34, Decibel! wrote:
> On Wed, Aug 29, 2007 at 08:37:26AM -0500, Ron Johnson wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 08/29/07 07:27, cluster wrote:
>>> OK, thanks. But what with the second question in which the
On Wed, Aug 29, 2007 at 08:37:26AM -0500, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/29/07 07:27, cluster wrote:
> > OK, thanks. But what with the second question in which the UPDATE is
> > based on a SELECT max(...) statement on another table? How can I ensure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/29/07 07:27, cluster wrote:
> OK, thanks. But what with the second question in which the UPDATE is
> based on a SELECT max(...) statement on another table? How can I ensure
> that no other process inserts a row between my SELECT max() and UPDATE
OK, thanks. But what with the second question in which the UPDATE is
based on a SELECT max(...) statement on another table? How can I ensure
that no other process inserts a row between my SELECT max() and UPDATE -
making my SELECT max() invalid?
A table lock could be an option but I am only in
On Tue, Aug 28, 2007 at 05:48:50PM +0200, cluster wrote:
> I need a way to perform a series of money transactions (row inserts)
> together with some row updates in such a way that integrity is ensured
> and performance is high.
>
> I have two tables:
> ACCOUNTS (
> account_id int,
> b
I need a way to perform a series of money transactions (row inserts)
together with some row updates in such a way that integrity is ensured
and performance is high.
I have two tables:
ACCOUNTS (
account_id int,
balance int
);
TRANSACTIONS (
transaction_id int,
source_
21 matches
Mail list logo
