From: | "Matthias Urlichs" <smurf(at)noris(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Matthias Urlichs" <smurf(at)noris(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: Heaps of read() syscalls by the postmaster |
Date: | 2000-05-19 19:31:44 |
Message-ID: | 20000519213144.E27730@noris.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
Tom Lane:
> "Matthias Urlichs" <smurf(at)noris(dot)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(at)noris(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-05-19 19:35:04 | Re: Performance (was: The New Slashdot Setup (includes MySql server)) |
Previous Message | The Hermit Hacker | 2000-05-19 19:01:28 | n-dimensional r-tree opclasses ... |