| From: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, "Bruce Momjian" <bruce(at)momjian(dot)us>, josh(at)agliodbs(dot)com |
| Subject: | Re: Dynamically sizing FSM? |
| Date: | 2007-01-10 04:55:13 |
| Message-ID: | 20070110125459.DC6B.ITAGAKI.TAKAHIRO@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm of the opinion that the solution to FSM being fixed-size is to keep
> it somewhere else, ie, on disk (possibly with some sort of cache in
> shared memory for currently-used entries).
What do you think dynamic allocation from shared_buffers? ie, remove
a buffer page in the shared buffer pool and use the 8kB of memory
for another purpose. To be sure, we don't free from out-of-FSM-memory,
but it can get rid of deciding the amount of FSM buffers.
I think we could use the above as "shared memory allocator".
It is useful for Dead Space Map, shared prepared statements, and so on.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-01-10 05:08:33 | Re: Dynamically sizing FSM? |
| Previous Message | ITAGAKI Takahiro | 2007-01-10 04:51:32 | Re: Load distributed checkpoint |