Re: Re: Heaps of read() syscalls by the postmaster
От | Matthias Urlichs |
---|---|
Тема | Re: Re: Heaps of read() syscalls by the postmaster |
Дата | |
Msg-id | 20000519213144.E27730@noris.de обсуждение исходный текст |
Ответ на | Re: Re: Heaps of read() syscalls by the postmaster (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Heaps of read() syscalls by the postmaster
|
Список | pgsql-hackers |
Hi, Tom Lane: > "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). The first part of the many-tables benchmark does 10000 CREATE TABLE/CREATE INDEX calls followed by 10000 DROP TABLE calls (i.e. you have ten thousand tables after the first step). The postmaster pricess grows from 15 to 50 MBtes during that time. The second part does 10000 CREATE TABLE/CREATE INDEX/DROP TABLE calls (i.e. it deletes every table immediately). Afterwards, the postmaster process is 85 MBytes big. > What is the benchmark doing exactly? > I can put a standalone version of the benchmark up for download someplace. > 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... > Not for that benchmark, certainly, but there are real-world applications which do play with lots of temporary tables for one reason or another. -- Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661 The quote was selected randomly. Really. | http://smurf.noris.de/ -- I want to dress you up as TALLULAH BANKHEAD and cover you with VASELINE and WHEAT THINS ... -- Zippy the Pinhead
В списке pgsql-hackers по дате отправления: