On Fri, Jan 06, 2006 at 04:49:09PM -0500, Tom Lane wrote:
> performance risk in the sort of scenario you are describing.
> (I'm not sure why it would manifest as transactions showing "INSERT
> waiting" state though.)
It's because of I/O. When you have a large number of updates, the
planner always
[EMAIL PROTECTED] writes:
> if the problem is caused by the the acquire lock->modify column->release
> lock on the table 1, then why does it increase significantly increase as the
> number of entries in the table 3 grows? The simulation maintains pretty much
> constant rate of new requests coming t
> > After digging through all the discussions of "INSERT waiting" problems I am
> > still not clear about the concensus about solving it.
> > ...
> > The only thing that I do not particulary like is that every INSERT
> > into this table has to adjust a counter column in a corresponding row of the
>
[EMAIL PROTECTED] writes:
> After digging through all the discussions of "INSERT waiting" problems I am
> still not clear about the concensus about solving it.
> ...
> The only thing that I do not particulary like is that every INSERT
> into this table has to adjust a counter column in a correspond
After digging through all the discussions of "INSERT waiting" problems I am
still not clear about the concensus about solving it.
I am running ration 6:1 SELECT:INSERT (insert fires up an UPDATE trigger
that hits a column in a table holding keys used by SELECT). I am looking at
doing about 2,00
