Re: Re: Heaps of read() syscalls by the postmaster

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Matthias Urlichs" <smurf(at)noris(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Heaps of read() syscalls by the postmaster
Date: 2000-05-19 18:46:13
Message-ID: 9371.958761973@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"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). 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2000-05-19 18:56:07 Re: Re: Heaps of read() syscalls by the postmaster
Previous Message Bruce Momjian 2000-05-19 18:39:27 Re: CVS commit broken