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 20000519135028.Q27730@noris.de
Whole thread Raw
In response to Re: Re: Heaps of read() syscalls by the postmaster  (Chris <chris@bitmead.com>)
List pgsql-hackers
Hi,

Chris:
> Matthias Urlichs wrote:
> 
> > You're right. It's the database's test/pg_attribute file,
> > which is a whopping 41 MBytes.
> 
> I suppose the obvious question is whether you copy the database to a new
> database, if the new database's pg_attribute is 41MB.

? I don't understand.

The database was created by a simple initdb/createdb. The test user was
created and given access, and the benchmark was started. The person
watching the benchmark subsequently fell asleep. ;-)

The reason for the huge size of this file might be the fact that the
full benchmark first creates a whole damn lot of tables, which it then
deletes. Apparently this process results in a rather suboptimal
pg_attribute/pg_index file. It also leaks memory (about 2k per table)
in the backend.

I'll restart the whole thing later today. We'll see if the problem comes
back. Hopefully not.

-- 
Matthias Urlichs  |  noris network GmbH   |   smurf@noris.de  |  ICQ: 20193661
The quote was selected randomly. Really.       |        http://smurf.noris.de/
-- 
Guitar players had their licks.


pgsql-hackers by date:

Previous
From: "Matthias Urlichs"
Date:
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Next
From: "Matthias Urlichs"
Date:
Subject: Re: Re: Heaps of read() syscalls by the postmaster