Re: BLOB performance test FYI

Joe,

> If someone is seriously interested in a patch to the current HTML
> doco, I'll gladly do it.

I would gladly welcome any updates/changes you want to make to the doc.
Also if there are things you would want changed on the
jdbc.postgresql.org website send them in as well.

> Wouldn't it make sense to separate the functionality of the OID data
> type - this is an ambigious use of types for different purposes.

Yes I agree. One of the problems the jdbc driver has with LO is that in
supporting them it has to assume that any column of type oid is a LO.
Thus if you call getObject on an oid column what should the driver do?
Well it depends on if you are using the oid for LOs or not. If you are
using the oid column to store oids other than LOs then the correct thing
to do would be to return an Interger/Long object, else a LO.

> What are the chances and issues with streaming binary data to the
backend?
> LO manager does it, but I'm not sure what else it introduces (separate
> transaction etc)

The backend doesn't have a way to stream data to it. However there are
two different ways to send data to the backend: 1) use the standard sql
mechanism of the FE/BE protocol in which the entire sql including all
data values are converted into a string and sent to the backend; 2) is
to use the FastPath protocol which allows you to call functions directly
on the backend. The FastPath protocol allows you to send binary data
without converting it to a string. The LO functionality in the driver
uses the FastPath protocol to call the underlying LO_xxx functions. So
while you can't stream data, you can break it into chunks and make
repeated calls to a function to send large amounts of data.

thanks,
--Barry

Joe Shevland wrote:
> Well said.
>
> I agree with Barry too that the best path to take is to try and improve
> the binary support, and that we're dealing with non-ideal options both
> ways. If someone is seriously interested in a patch to the current HTML
> doco, I'll gladly do it.
>
> Wouldn't it make sense to separate the functionality of the OID data
> type - this is an ambigious use of types for different purposes.
>
> What are the chances and issues with streaming binary data to the backend?
> LO manager does it, but I'm not sure what else it introduces (separate
> transaction etc)
>
> Regards,
> Joe
>
>
>>-----Original Message-----
>>From: pgsql-jdbc-owner(at)postgresql(dot)org
>>[mailto:pgsql-jdbc-owner(at)postgresql(dot)org]On Behalf Of Marin Dimitrov
>>Sent: Thursday, 18 April 2002 8:32
>>Cc: pgsql-jdbc(at)postgresql(dot)org
>>Subject: Re: [JDBC] BLOB performance test FYI
>>
>>
>>
>>----- Original Message -----
>>From: "Barry Lind"
>>
>>
>>>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.
>>
>>the docs do not mention that storing even a 500KB of binary data
>>is 40 times
>>slower with byte when compared to LO
>>
>>besides, 500KB is all but the "very large value" that is mentioned in
>
> the
>
>>docs
>>
>>provided that people have outlined the problems that lead to the poor
>
> byte
>
>>performance (the backend parses the input) and that these problems seem
>
> to
>
>>be unresolvable, then wouldn't it be a better mid-term solution
>>to switch to
>>LO and hope for improvements related to LOs in next releases rather than
>>using byte at all?
>>
>>
>> Marin
>>
>>----
>>"...what you brought from your past, is of no use in your present. When
>>you must choose a new path, do not bring old experiences with you.
>>Those who strike out afresh, but who attempt to retain a little of the
>>old life, end up torn apart by their own memories. "
>>
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>>message can get through to the mailing list cleanly
>>
>