2012/11/20 Heikki Linnakangas <hlinnakan...@vmware.com>: > On 19.11.2012 15:17, Pavel Stehule wrote: >> >> I tested this patch and I can confirm, so this patch can increase >> speed about 16-22% (depends on IO waits, load type). > > > Thanks for the review. > > I spent some more time on this, continuing with the thought that perhaps it > would be better if get_str_from_var() didn't scribble on its input. I ended > up with the attached patch, which contains a bunch of small tweaks: > > * Add init_var_from_num() function. This is the same as > set_var_from_num_nocopy in the original patch, but it doesn't require the > caller to have called init_var() first. IMHO this makes the calling code > slightly more readable. Also, it's now more evident what these vars are: the > digits array points to original array in the original Datum, but 'buf' is > NULL. This is the same arrangement that's used in the constant NumericVars > like const_zero. > > * get_str_from_var() no longer scribbles on its input. I noticed that it's > always called with a dscale that comes from the input var itself. In other > words, the rounding was unnecessary to begin with. I simply removed the > dscale argument and the round_var() call from get_str_from_var(). If a > someone wants to display a string with different dscale in the future, he > can simply call round_var() before get_str_from_var(). > > * numericvar_to_int8() no long scribbles on its input either. It creates a > temporary copy to avoid that. To compensate, the callers no longer need to > create a temporary copy, so the net # of pallocs is the same, but this is > nicer. (there's room for a micro-optimization to avoid making the temporary > copy numericvar_to_int8() when the argument is already suitably rounded - I > left that our for now, dunno if it would make any difference in practice) > > * use a constant for the number 10 in get_str_from_var_sci(), when > calculating 10^exponent. Saves a palloc() and some cycles to convert integer > 10 to numeric. > > Comments? Assuming no-one sees some fatal flaw in this, I'll commit this > tomorrow.
I have no objections all regression tests passed, no warnings - has a sense Regards Pavel > > - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
