> I still don't see how dirty reads can solve the RI problems.
> If Xact A deletes a PK while Xact B inserts an FK, one of
> them will either see the new reference or the PK gone. But
> from a transactional POV it depends on if the opposite Xact
> finally commits or n
Mikheev, Vadim wrote:
> > > So, I've run simple test (below) to check this. Seems that 7.1
> > > is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> > > triggers is quite bad for performance.
> > > Also, we should add new TODO item: implement dirty reads
> > > and use them in RI tri
> >> What is the default commit delay now?
>
> > As before 5 * 10^(-6) sec - pretty the same as sleep(0) -:)
> > Seems CommitDelay is not very useful parameter now - XLogFlush
> > logic and fsync time add some delay.
>
> There was a thread recently about smarter ways to handle shared fsync
> of
[ Charset ISO-8859-1 unsupported, converting... ]
> I've run tests (with 50 .. 250 simult users) for some PG project
> of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
> 3 times slower than 7.0.3 (nofsync). It was not the best day in
> my life - WAL looked like big bottleneck -:(
At 16:27 9/12/00 +0900, Tatsuo Ishii wrote:
>It might be interesting
>moving data/pg_xlog to a separate disk drive and see how it performs
>better.
Good idea. One of the fundamental rules with Dec/RDB is to put the
XLOG-equivant on a different drive from *any* database-related file.
Another setti
> I've run tests (with 50 .. 250 simult users) for some PG project
> of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
> 3 times slower than 7.0.3 (nofsync). It was not the best day in
> my life - WAL looked like big bottleneck -:(
>
> But finally I've realized that this test make
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> And we always will have to enable fsync when comparing our
> performance with other DBes.
Of course, but when people say "it's slower than 7.0.3+nofsync"
I think that turning off fsync makes a fairer comparison there.
>> also reduce the WAL commit
> > I have only one explanation: it reduces number of transactions ready
> > to commit (because of the same FK writers will wait till first one
> > committed - ie log fsynced) and WAL commit performance
> > greatly depends on how many commits were done by single log fsync.
> > 7.0.3+nofsync commi
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> I have only one explanation: it reduces number of transactions ready
> to commit (because of the same FK writers will wait till first one
> committed - ie log fsynced) and WAL commit performance greatly depends
> on how many commits were done by singl
> > So, I've run simple test (below) to check this. Seems that 7.1
> > is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> > triggers is quite bad for performance.
> > Also, we should add new TODO item: implement dirty reads
> > and use them in RI triggers.
>
> That would fix RI tr
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> So, I've run simple test (below) to check this. Seems that 7.1
> is faster than 7.0.3 (nofsync), and that SELECT FOR UPDATE in RI
> triggers is quite bad for performance.
> Also, we should add new TODO item: implement dirty reads
> and use them in RI
I've run tests (with 50 .. 250 simult users) for some PG project
of my company. 7.1 was 3 times faster than 7.0.3 (fsync) but near
3 times slower than 7.0.3 (nofsync). It was not the best day in
my life - WAL looked like big bottleneck -:(
But finally I've realized that this test makes ~3 FK inse
12 matches
Mail list logo
