Oliver Jowett wrote:> On Thu, Jul 03, 2003 at 09:50:53AM -0400, Fernando Nasser
wrote:
>
>
>>>From a quick look at your patch, though, it appears to only touch
>>>setBinaryStream()? From memory, we use setBytes(), so this may not be an
>>>issue for us (although we'd like to keep the option of using
>>>setBinaryStream()).
>>>
>>
>>Yes, the idea was use setBinaryStream() if you want to use this method
>>(we cannot do much for setBytes() anyway as we need the stream). Of
>>course, Barry's suggestion makes it much better as it allows one to use
>>setBinaryStream() for small data as well.
>
>
> Isn't streaming a win for setBytes() with large bytearrays? If I have an
> existing 1mb byte array to insert, the current driver will need 2-3mb of
> temporary string space for setBytes(), I think?
>
> I suppose the app can always wrap it in a ByteArrayInputStream and use
> setBinaryStream(), though.
>
That is the idea.
We could create the stream in the driver in the setBytes() method but as I
mentioned, the new frontend-backend protocol has a mechanism that we can use to
send the data so we did not want to get too sofisticated in the legacy fix.
>
>>If there is a lot of interest in this fix for 7.3 and 7.2 backends, and
>>you can convince Barry to incorporate it (with his proposed changes) in
>>the driver, I can ask for time to get it in shape for submission. But I
>>won't be able to do it unless it goes into the main line of code -- I
>>already have to work on the 7.4 version (V3 protocol).
>
>
> We don't benefit from the patch as we don't deal with large bytea fields, I
> just wanted to make sure our insert performance didn't suffer if the patch
> did get applied. It sounds like that won't be a problem, thanks for
> clarifying things.
>
You are welcome.
Best regards,
Fernando
--
Fernando Nasser
Red Hat - Toronto E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9