Re: copy vs. C function

Поиск
Список
Период
Сортировка
От Jon Nelson
Тема Re: copy vs. C function
Дата
Msg-id CAKuK5J2NbUDoGeW5WA-bBWQE5fcUUd1dKBS30ArL120pXfbC_Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: copy vs. C function  (Craig Ringer <ringerc@ringerc.id.au>)
Список pgsql-performance
On Sat, Dec 10, 2011 at 8:32 PM, Craig Ringer <ringerc@ringerc.id.au> wrote:
> On 12/11/2011 09:27 AM, Jon Nelson wrote:
>>
>> The first method involved writing a C program to parse a file, parse
>> the lines and output newly-formatted lines in a format that
>> postgresql's COPY function can use.
>> End-to-end, this takes 15 seconds for about 250MB (read 250MB, parse,
>> output new data to new file -- 4 seconds, COPY new file -- 10
>> seconds).
>
> Why not `COPY tablename FROM /path/to/myfifo' ?

If I were to do this in any sort of production environment, that's
exactly what I would do. I was much more concerned about the /huge/
difference -- 10 seconds for COPY and 120 seconds for (INSERT INTO /
CREATE TABLE AS / whatever).

>> The next approach I took was to write a C function in postgresql to
>> parse a single TEXT datum into an array of C strings, and then use
>> BuildTupleFromCStrings. There are 8 columns involved.
>> Eliding the time it takes to COPY the (raw) file into a temporary
>> table, this method took 120 seconds, give or take.
>>
>> The difference was /quite/ a surprise to me. What is the probability
>> that I am doing something very, very wrong?
>
> Have a look at how COPY does it within the Pg sources, see if that's any
> help. I don't know enough about Pg's innards to answer this one beyond that
> suggestion, sorry.

Ack.

Regarding a subsequent email, I was using full transactions.


--
Jon

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

Предыдущее
От: Sam Gendler
Дата:
Сообщение: Re: copy vs. C function
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Common slow query reasons - help with a special log