memory dilemma
| От | Karel Zak - Zakkr |
|---|---|
| Тема | memory dilemma |
| Дата | |
| Msg-id | Pine.LNX.3.96.991227124802.6398D-100000@ara.zf.jcu.cz обсуждение исходный текст |
| Ответы |
Re: [HACKERS] memory dilemma
Re: [HACKERS] memory dilemma |
| Список | 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.
AndI don't know how check when memory is free (lose) and a routine must reallocs memory again (if transaction finish PG
memorymanagementnot 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- usepallocated memory and not use cache buffer. (It is my favourite variant.)
not use cache - hmm.. but I like fast routines (my currentto_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@zf.jcu.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)
-----------------------------------------------------------------------
В списке pgsql-hackers по дате отправления: