"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.
Hmm. So the space *is* leaked. Grumble. Another TODO list item...
thanks for following up on it.
>> What is the benchmark doing exactly?
>>
> I can put a standalone version of the benchmark up for download
> someplace.
OK. If this benchmark comes with MySQL, though, just tell us where
to look in their tarball --- no need for you to provide an alternate
distribution when we can get it from their server...
>> 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.
Agreed, but I thought the space would get reclaimed when you deleted the
temp table. That's definitely a bug.
regards, tom lane
