On Thu, 9 Dec 1999, Don Baccus wrote:
> At 01:40 PM 12/27/99 +0100, Karel Zak - Zakkr wrote:
>
> > 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?
Sorry, but it is not good argument. If any routine (in the query path)
spend time is not interesting write (other) fast routine? No, we must
try rewrite this slowly part to faster version.
*Very* simpl test over 10000 rows:
$ time psql test -c "select date_part('second', d)
from dtest;" -o /dev/null
real 0m0.504s
user 0m0.100s
sys 0m0.000s
$ time psql test -c "select to_char(d, 'SI') from
dtest;" -o /dev/null
real 0m0.288s
user 0m0.100s
sys 0m0.000s
> Trivial cases like "select to_char('now'::datetime,...)" can't in
> general be cached anyway, since 'now' is always changing...
No, you not understend me. I want cached 'format-picture':
run 10000 x select to_char(datetime, 'HH24:MI:SI FMMonth YYYY');
yes, 'datetime' can always changing, but 'HH24:MI:SI FMMonth YYYY' not,
and this format-picture must be always parsed. It is terrible always call
to_char() parser, if I can use cache for it.
> Your caching code needs to guarantee that it can't leak memory
> in any circumstance. In environments where database servers
> run 24/7 that's far more important than minor increases in
> speed.
Yes, I agree - robus SQL is more importent, but always say "speed is not
interesting, we can robus only" is way to robus-snail-SQL.
I want nice-robus-fast-SQL :-) Karel