On Tue, 23 Sep 2014 14:12:22 +0200 Thomas Kellerer <spam_eater@xxxxxxx> wrote: > Sameer Kumar schrieb am 23.09.2014 um 07:24: > > I am working with a vendor and planning to deploy their application > > on PostgreSQL as backend. They have cautioned the customer that > > PostgreSQL's jdbc driver v9.1 (build 900) has issues which causes > > deadlocks while "wide record inserts". > > Can you be a bit more explicit? > I have never heard the term "wide record inserts" before I've heard these terms before. "Wide" generally means at least one of the following: * A large number of columns * At least 1 column with a lot of data Of course, both of those criteria are incredibly subjective. How many columns is a "large" number? How much data is a "lot"? It generally boils down to he fact that pushing a lot of data (whether many columns or a single column with a lot of data) takes longer than pushing small amounts of data (big surprise) and as a result, the statistical chance that the operatin will collide with a conflicting operation (causing, in this case, a deadlock) is increased. As you mention, it's usually something that people with poorly written applications complain about. I.e. "our application works just fine in our test environment, so your server must be too slow ... get a faster server" Of course, the real problem is that the application was written with a large number of braindead assumptions (things will always be fast; our tests never encounter deadlocks, so they can't happen, etc) I've dealt directly with this back in my consulting days: clients who insisted that the correct way to fix their crashes was to buy faster hardware. The annoying thing is that such an approach _appears_ to fix the problem, because the faster hardware causes the chance of the problem occuring to be less, and in the mind of people who don't understand concurrent programming, that's "fixed". The amount of really badly written software out there is a very large number. -- Bill Moran I need your help to succeed: http://gamesbybill.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
