Re: INSERT times - same storage space but more fields -> much slower inserts

Поиск
Список
Период
Сортировка
Искать
От
Tom Lane
Тема
Re: INSERT times - same storage space but more fields -> much slower inserts
Дата
Msg-id
25350.1239756009@sss.pgh.pa.us
Ответ на
Список
Дерево обсуждения
INSERT times - same storage space but more fields -> much slower inserts Craig Ringer <craig@postnewspapers.com.au>
Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost <sfrost@snowman.net>
Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling <matthew@flymine.org>
Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost <sfrost@snowman.net>
Re: INSERT times - same storage space but more fields -> much slower inserts Craig Ringer <craig@postnewspapers.com.au>
Re: INSERT times - same storage space but more fields -> much slower inserts Stephen Frost <sfrost@snowman.net>
Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling <matthew@flymine.org>
Re: INSERT times - same storage space but more fields -> much slower inserts Matthew Wakeling <matthew@flymine.org>
Re: INSERT times - same storage space but more fields -> much slower inserts Tom Lane <tgl@sss.pgh.pa.us>
Craig Ringer  writes:
> Unlike PQexecPrepared(...), binary-format COPY doesn't handle endian and
> type size issues for you. You need to convert the data to the database
> server's endianness and type sizes, but I don't think the PostgreSQL
> protocol provides any way to find those out.

The on-the-wire binary format is much better specified than you think.
(The documentation of it sucks, however.)  It's big-endian in all cases
and the datatype sizes are well defined.

			regards, tom lane
В списке pgsql-performance по дате отправления
От: Craig Ringer
Дата:
От: Brian Cox
Дата:
FAQ