Re: Speedup usages of pg_*toa() functions
От | David Rowley |
---|---|
Тема | Re: Speedup usages of pg_*toa() functions |
Дата | |
Msg-id | CAApHDvqLqSYZY2T3g3SUuOcHwbLbo86SAtKmDEwseumDx65+0A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Speedup usages of pg_*toa() functions (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: Speedup usages of pg_*toa() functions
|
Список | pgsql-hackers |
On Thu, 11 Jun 2020 at 18:52, Andrew Gierth <andrew@tao11.riddles.org.uk> wrote: > > >>>>> "David" == David Rowley <dgrowleyml@gmail.com> writes: > > David> Pending any objections, I'd like to push both of these patches > David> in the next few days to master. > > For the second patch, can we take the opportunity to remove the > extraneous blank line at the top of pg_ltoa, and add the two missing > "extern"s in builtins.h for pg_ultoa_n and pg_ulltoa_n ? > > David> Anyone object to changing the signature of these functions in > David> 0002, or have concerns about allocating the maximum memory that > David> we might require in int8out()? > > Changing the function signatures seems safe enough. The memory thing > only seems likely to be an issue if you allocate a lot of text strings > for bigint values without a context reset, and I'm not sure where that > would happen (maybe passing large bigint arrays to pl/perl or pl/python > would do it?) I ended up chickening out of doing the larger allocation unconditionally. Instead, I pushed the original idea of doing the palloc/memcpy of the length returned by pg_lltoa. That gets us most of the gains without the change in memory usage behaviour. Thanks for your reviews on this. David
В списке pgsql-hackers по дате отправления: