Re: Re: Heaps of read() syscalls by the postmaster - Mailing list pgsql-hackers

From Matthias Urlichs
Subject Re: Re: Heaps of read() syscalls by the postmaster
Date
Msg-id 20000519213144.E27730@noris.de
Whole thread Raw
In response to Re: Re: Heaps of read() syscalls by the postmaster  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Heaps of read() syscalls by the postmaster
List 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 by date:

Previous
From: The Hermit Hacker
Date:
Subject: n-dimensional r-tree opclasses ...
Next
From: Tom Lane
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))