| 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: | Whole Thread | Raw Message | 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 |