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)
-----------------------------------------------------------------------
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 |