Re: Re: Heaps of read() syscalls by the postmaster
От | Tom Lane |
---|---|
Тема | Re: Re: Heaps of read() syscalls by the postmaster |
Дата | |
Msg-id | 9371.958761973@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Heaps of read() syscalls by the postmaster ("Matthias Urlichs" <smurf@noris.net>) |
Ответы |
Re: Re: Heaps of read() syscalls by the postmaster
Re: Re: Heaps of read() syscalls by the postmaster |
Список | pgsql-hackers |
"Matthias Urlichs" <smurf@noris.net> writes: > NB: The same benchmark revealed that CREATE TABLE (or maybe it's CREATE > INDEX) leaks about 2k of memory. Following up on this other point: this could simply be the new table's relcache entry (2K seems high though). Currently the relcache doesn't have any procedure for discarding uninteresting entries, so once a table is referenced by a backend that relcache entry will be there until the backend quits or has some specific reason for flushing the entry. I wouldn't expect a CREATE TABLE / DELETE TABLE cycle to show any memory leak, since the DELETE would flush the relcache entry. But creating a few thousand tables in a row would start to eat up memory a little bit. What is the benchmark doing exactly? We could add a mechanism for aging relcache entries out of the cache when they haven't been touched recently, but so far it hasn't seemed worth the trouble... regards, tom lane
В списке pgsql-hackers по дате отправления: