>> >	not use cache - hmm.. but I like fast routines (my current
>> >	to_char() implementation is faster (20-50%) than current 
>> >	date_part()).
>> 
>> While fast routines are nice indeed, isn't it true in practice
>> that to_char() times will be swamped by the amount of time to
>> parse, plan, and execute a query in most cases?
Although not in PG (yet...) we draw reports that contain sometimes hundreds
of thousands, sometimes (often) millions of rows, and each row has at least
two to_char calls.  Any speed improvement is significant.

Assuming an improvement of 0.22s per 10000 rows, over 5 million rows, that's
nearly four minutes.  That's quite a lot on a report that normally takes
about ten or fifteen minutes to run.  Of course, the servers we run on are
probably a lot more powerful that the one that Karl ran his test on, so the
improvement is likely to be less, but still significant.


MikeA

Mon, 27 Dec 1999 16:23:43 +0200
"Ansley, Michael" <Michael.Ansley@intec.co.za>
RE: [HACKERS] memory dilemma