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)
|
Список | 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 по дате отправления: