Re: BYTEA Fields and Memory Consumption

Hi Ramesh,

(2011/04/15 8:48), Ramesh Reddy wrote:
> In my experience even when using 'lo' the driver only got the first
> chunk of data which is equal to the length of the buffer that client
> provided and never went back to ask for next chunk.

Clients have to call some special API/methods provided by the
interface they are using, e.g. ODBC native apps calls SQLPutData(),
ADO apps calls AppendChunk().

regards,
Hiroshi Inoue

> Also, I am not sure how one can read multiple blocks from client code?
>
> Ramesh..
>
> On Fri, 2011-04-15 at 08:42 +0900, Hiroshi Inoue wrote:
>> (2011/04/14 21:17), Raiford(at)labware(dot)com wrote:
>>> Hi Hiroshi-san,
>>>
>>> Thank you for your response. Could you clarify one thing for me? Are you
>>> suggesting that when using an lo datatype with the lo module installed,
>>
>> You don't have to install the lo module. Please type
>>
>> create domain lo as oid;
>>
>> and use the lo type.
>>
>>> the ODBC driver automatically sends the data in pieces?
>>
>> Yes.
>>
>> regards,
>> Hiroshi Inoue
>>
>> > Or does it only
>>> open the possibility for me to use the lo_import() function? If
>>> everything is handled internally in the ODBC driver, it would certainly
>>> help a lot :)
>>>
>>> Jon
>>>
>>> From: Hiroshi Inoue<inoue(at)tpf(dot)co(dot)jp>
>>> To: Raiford(at)labware(dot)com
>>> Cc: pgsql-odbc(at)postgresql(dot)org
>>> Date: 04/13/2011 11:42 PM
>>> Subject: Re: [ODBC] BYTEA Fields and Memory Consumption
>>> Sent by: pgsql-odbc-owner(at)postgresql(dot)org
>>> ------------------------------------------------------------------------
>>>
>>> Hi,
>>>
>>> (2011/04/13 21:09), Raiford(at)labware(dot)com wrote:
>>> > I have an issue where even though I break a large BYTEA object up into
>>> > multiple pieces, the ODBC driver just rejoins the pieces in memory and
>>> > tries to send it all out at once. I took a look at the code and sure
>>> > enough the driver just keeps reallocating memory for each chunk of data
>>> > that I add.
>>>
>>> Yes you are right.
>>>
>>> > Can I assume Postgres has no mechanism to send this data
>>> > across the wire in pieces? Are there any common practices for dealing
>>> > with this?
>>>
>>> Please try lo type instead of bytea type.
>>>
>>> regards,
>>> Hiroshi Inoue