RE: [HACKERS] memory dilemma - Mailing list pgsql-hackers

From Ansley, Michael
Subject RE: [HACKERS] memory dilemma
Date
Msg-id 1BF7C7482189D211B03F00805F8527F748C38B@S-NATH-EXCH2
Whole thread Raw
List pgsql-hackers
>> >    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


pgsql-hackers by date:

Previous
From: Karel Zak - Zakkr
Date:
Subject: Re: [HACKERS] memory dilemma
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] memory dilemma