From: | Don Baccus <dhogaza(at)pacifier(dot)com> |
---|---|
To: | Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>, pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] memory dilemma |
Date: | 1999-12-09 11:17:33 |
Message-ID: | 3.0.1.32.19991209031733.00ecfd20@mail.pacifier.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Trivial cases like "select to_char('now'::datetime,...)" can't in
general be cached anyway, since 'now' is always changing...
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.
- Don Baccus, Portland OR <dhogaza(at)pacifier(dot)com>
Nature photos, on-line guides, Pacific Northwest
Rare Bird Alert Service and other goodies at
http://donb.photo.net.
From | Date | Subject | |
---|---|---|---|
Next Message | Don Baccus | 1999-12-09 15:44:30 | Re: PostgreSQL front ends (was Re: [HACKERS] Parallel regress tests (was Re: FOREIGN KEY andshift/reduce)) |
Previous Message | Oliver Elphick | 1999-12-09 11:14:28 | Re: [HACKERS] More initdb follies |