On Tue, 12 Jan 2010, Bob Dusek wrote:
Each of the concurrent clients does a series of selects, inserts, updates, and deletes. The requests would generally never update or delete the same rows in a table. However, the requests do generally write to the same tables. And, they are all reading from the same tables that they're writing to. For the inserts, I imagine they are blocking on access to the sequence that controls the primary keys for the insert tables.
I'm going to have to bow out at this stage, and let someone else who knows more about what gets locked in a transaction help instead. The sequence may be significant, but I would have thought it would have to be something a bit bigger that is gumming up the works.
I'm really sorry. I'm using gmail's interface.
Actually, you weren't doing anything particularly wrong as it turns out. It is partly a case of alpine being too clever for its own good, just as Kevin pointed out. My mail reader is taking the "most preferred" mime alternative, which is the HTML version, and interpreting it to its best ability, which isn't very well. It is the email that says which alternative is preferred, by the way. I have just forced alpine to view the plain text version instead, and it is much better.
I just saw the "<< Plain Text" formatter at the top of this compose message. But, if I convert it to Plain Text now, I may lose my portion of the message. I'll use the Plain Text when posting future messages.
To be honest, that's always a good idea, although you didn't actually do wrong. I do know people whose spam filters immediately discard emails that contain a HTML alternative - that's taking it to the extreme!
Matthew -- Beware of bugs in the above code; I have only proved it correct, not tried it. --Donald Knuth -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
