Re: Inefficient escape codes.

From: "Rodrigo Madera" <rodrigo(dot)madera(at)gmail(dot)com>
To: <Nrder-Tuitje(at)svr1(dot)postgresql(dot)org>, "Marcus" <noerder-tuitje(at)technology(dot)de>, "IMB Recipient 1" <mspop3connector(dot)gfnobrega(at)planae2004(dot)local>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Inefficient escape codes.
Date: 2005-10-21 17:15:58
Message-ID: 000501c5d663$1a907bb0$7e00a8c0@Planae2004.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


I guess, You should check, if a blob field and large object access is suitable for you - no escaping etc, just raw binary large objects.

AFAIK, PQExecParams is not the right solution for You. Refer the "Large object" section:

"28.3.5. Writing Data to a Large Object
The function
int lo_write(PGconn *conn, int fd, const char *buf, size_t len);writes len bytes from buf to large object descriptor fd. The fd argument must have been returned by a previous lo_open. The number of bytes actually written is returned. In the event of an error, the return value is negative."

Well, I read that large objects are kept in only ONE table. No matter what, only the LOID would be kept. I can't affor that since I hav lots of tables (using the image-album-app analogy, imagine that we have pictures from several cities, each one corresponding to a city, like Memphis_Photos, Chicago_Photos, etc.).

This is one major drawback, isn't it?

Rodrigo

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Conway 2005-10-21 21:44:47 Re: What gets cached?
Previous Message Rodrigo Madera 2005-10-21 16:59:30 Re: Inefficient escape codes.