Re: Parsing speed (was Re: pgstats_initstats() cost)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parsing speed (was Re: pgstats_initstats() cost)
Дата
Msg-id 16354.1060720890@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parsing speed (was Re: pgstats_initstats() cost)  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Parsing speed (was Re: pgstats_initstats() cost)  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> You probably know but I'll quickly outline it to point out the
> differences, as I see them, from the 'COPY' ability.  Basically the user
> defines their own C structure and then malloc's an array of them.  The
> user then tells the database the type, offset from start of structure
> and the skip (size of structure) for each column returned by the select
> statement.  The user can then do 'bulk' grabs with a single command into
> the memory space allocated, doing more than one and changing the offsets
> inbetween if more is returned than was initially allocated for.  The
> user can realloc or allocate new segments and do their own handling of
> the segments if they choose.

[shrug]  That seems like a substantial increase in API complexity for
at best marginal performance gains.  What does it gain for the user to
malloc space rather than libpq?
        regards, tom lane


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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Parsing speed (was Re: pgstats_initstats() cost)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Parsing speed (was Re: pgstats_initstats() cost)