Re: BLOB performance test FYI - Mailing list pgsql-jdbc

From Barry Lind
Subject Re: BLOB performance test FYI
Date
Msg-id 3CBDF801.4080801@xythos.com
Whole thread Raw
In response to Re: BLOB performance test FYI  ("Joe Shevland" <jshevland@j-elite.com>)
List pgsql-jdbc
Joe,

The real problem is that postgres does not have a good datatype for
storing large binary (or large character) objects.  There are currently
two options each less than ideal.  The jdbc driver can only map into one
of the available types and until something better gets put into the
backend there is no idea choice.

Patches to the documentation that help improve everyones understanding
of the issues involved are certainly welcome.

thanks,
--Barry



Joe Shevland wrote:
>>No I don't think it is crazy when you look at the other side of the
>>coin.  LargeObject's have their own set of problems and you need to
>>compare the pros and cons of each solution.  The reason I believe that
>>bytea wins over LargeObjects is because of the symantics of delete.
>
>
> I do agree here, LO's have their own insurmountable issues.
>
> [snip]
>
>>the oid for the LargeObject.  The casual user of binary data (which can
>>range from a few bytes to hundreds of megs) should have something out of
>>the box that works symantically as they would expect IMHO.
>
>
> I totally agree; however as shown the bytea type *will not work* for data
> this size (esp. not hundreds of megs). Both storage and retrieval from the
> client. !!
>
>
>>I find that
>>many users of bytea are storing gifs and html pages for web sites which
>>generally are small enough such that bytea works fine.
>
>
> Well, I disagree... even a few kilobytes has shown to be substandard in
> storing.
>
>
>>This is all explained to some degree in the documentation for 7.2.  It
>>is left as a choice to the user to use the datatype best suited for
>>their circumstances given the pros and cons of the different
>
> alternatives.
>
> Again its not really well explained at all in the doco (I'm writing a
> primer that fixes code bugs in the examples (setBlob() isn't a method ;)
> and clarifies these issues). It is left as a choice I agree, but
> defaulting to the bytea type IMHO is a shocking thing to do... if I hadn't
> done this investigation and gone ahead with my application using 'bytea',
> it would be brought to its knees, thats if it makes it to its knees after
> the memory issues.
>
> Joe



pgsql-jdbc by date:

Previous
From: "Marin Dimitrov"
Date:
Subject: Re: BLOB performance test FYI
Next
From: "Joe Shevland"
Date:
Subject: Re: BLOB performance test FYI