Re: Inefficient escape codes.

Поиск
Список
Период
Сортировка
Искать
От
Rodrigo Madera
Тема
Re: Inefficient escape codes.
Дата
Msg-id
000501c5d663$1a907bb0$7e00a8c0@Planae2004.local
Ответ на
Re: Inefficient escape codes. (Nörder-Tuitje, Marcus)
Список
Дерево обсуждения
Re: Inefficient escape codes. "Merlin Moncure" <merlin.moncure@rcsonline.com>

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


В списке pgsql-performance по дате отправления
От: jnevans@gmail.com
Дата:
Сообщение: impact of stats_command_string
От: Kishore B
Дата:
FAQ