Re: wide row insert via Postgres jdbc driver

On Tue, Sep 23, 2014 at 9:24 PM, Bill Moran <wmoran(at)potentialtech(dot)com>
wrote:

> On Tue, 23 Sep 2014 14:12:22 +0200
> Thomas Kellerer <spam_eater(at)gmx(dot)net> 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
>
> ​Sorry for using the generic term. Yes the explanation is correct​. When I
said wide row, I meant "bytea" columns being part of table.

> 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.
>
> I guess I understand the explanation here.​

> 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.

​Can not agree any more... :)
​
​
​Let me get back to the vendor with this. I am sure they are not going to
like it (no one likes to admit they are wrong) :)​

Best Regards,

*Sameer Kumar | Database Consultant*

*ASHNIK PTE. LTD.*

101 Cecil Street, #11-11 Tong Eng Building, Singapore 069533

M: *+65 8110 0350* T: +65 6438 3504 | www.ashnik.com

*[image: icons]*

[image: Email patch] <http://www.ashnik.com/>

This email may contain confidential, privileged or copyright material and
is solely for the use of the intended recipient(s).