Re: [HACKERS] memory dilemma

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.

In response to

Responses

Browse pgsql-hackers by date

  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