memory dilemma

From: Karel Zak - Zakkr <zakkr(at)zf(dot)jcu(dot)cz>
To: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: memory dilemma
Date: 1999-12-27 12:40:49
Message-ID: Pine.LNX.3.96.991227124802.6398D-100000@ara.zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

I have dilemma with PG's memory. I'am finishing with to_char()
implementation and I try use internal cache buffer in this routines.
This cache is used if a to_char() format-picture (which going to the
internal to_char parser) is equal as previous and to_char's parser is
skiped. It is very good, because speed rise (20%).

A problem is how implement this cache:

via palloc - It is standard in PG, but it is problem, because
memory contents is not persisten across transactions. And
I don't know how check when memory is free (lose) and a routine
must reallocs memory again (if transaction finish PG memory
management not zeroizing (reset) memory and any "if( buffer )"
still affects as good memory).

via malloc - (Now used). It is good, because buffer is persistent.
This variant is (example) use in regexp utils in PG now.
But is it nice?

via a static buffer - but how long? Terrible. Or set any default
size for this buffer, and if format-picture will bigger - use
pallocated memory and not use cache buffer. (It is my favourite
variant.)

not use cache - hmm.. but I like fast routines (my current
to_char() implementation is faster (20-50%) than current
date_part()).

Any idea? Please.

Karel

PS. IMHO - add to PostgreSQL any *across transactions persistent*
memory managemet?

----------------------------------------------------------------------
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> http://home.zf.jcu.cz/~zakkr/

Docs: http://docs.linux.cz (big docs archive)
Kim Project: http://home.zf.jcu.cz/~zakkr/kim/ (process manager)
FTP: ftp://ftp2.zf.jcu.cz/users/zakkr/ (C/ncurses/PgSQL)
-----------------------------------------------------------------------

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ansley, Michael 1999-12-27 13:12:02 pg_dump update
Previous Message Michael Robinson 1999-12-27 11:35:52 Re: [HACKERS] database replication