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 <noerder-tuitje@technology.de>)
Список 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


В списке pgsql-performance по дате отправления:

Предыдущее
От: jnevans@gmail.com
Дата:
Сообщение: impact of stats_command_string
Следующее
От: Kishore B
Дата:
Сообщение: Need help in setting optimal configuration for a huge database.