From: | alex-lists-pgsql(at)yuriev(dot)com |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: INSERT waiting under heavy load |
Date: | 2006-01-06 20:16:57 |
Message-ID: | 20060106201657.GB1890@s2.yuriev.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> > 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
> > (table1) via (table3->table2->table1) path.
>
> Well, if there are only a few rows in table1, then this design is
> inherently going to lose big. Any two transactions trying to update the
> same table1 row are going to conflict and one will have to wait for the
> other to complete. Rethink the need for those counters.
I appreciate that it is most likely not the best design though i expect
reasonable distribution of UPDATE hits against the first table when the
number of rows increases.
What I do not understand is this:
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 to table 3.
Alex
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-06 20:52:08 | Re: INSERT waiting under heavy load |
Previous Message | alex-lists-pgsql | 2006-01-06 18:42:27 | INSERT waiting under heavy load |