> > 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 triggers, I guess, but what about plain SELECT FOR
> UPDATE being used by applications?
What about it? Application normally uses exclusive row locks only when
it's really required by application logic.
Exclusive PK locks are not required for FK inserts by RI logic,
we just have no other means to ensure PK existence currently.
Keeping in mind that RI is used near in every application I would
like to see this fixed. And ppl already complained about it.
> Why exactly is SELECT FOR UPDATE such a performance problem for 7.1,
> anyway? I wouldn't have thought it'd be a big deal...
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 commit performance doesn't depend on this factor.
Vadim
