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
Дата: