Return-Path: mao
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA14213; Wed, 2 Sep 92 13:01:19 -0700
Message-Id: <9209022001.AA14213@postgres.Berkeley.EDU>
From: <mao@postgres.berkeley.edu>
Subject: Re: memory and performance under 4.0.1
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
In-Reply-To: Your message of Wed, 02 Sep 92 12:50:39 PST.
             <9209021950.AA14087@postgres.Berkeley.EDU> 
Date: Wed, 02 Sep 92 12:59:27 PDT

In message <9209021950.AA14087@postgres.Berkeley.EDU> you write:

> Can anyone explain this behavior and/or suggest ways of preventing it?

what is the query mix you're running to set up the database?  if you're
copying in a very large number of tuples, postgres will allocate and
hold memory for all of them until the end of transaction.  unless your
system supports negative sbrk (i know of none that do), this memory will
remain allocated to the backend after the transaction completes, even
though postgres calls free() on it.  however, it shouldn't be resident;
that is, your RSS should be reasonable, even if the total amount of
virtual memory the os is reserving for you is large.

we're aware of modest slowdowns in 4.0.1 over 3.1, but nothing approaching
a factor of two.  can you quantify this more precisely?

one way to speed up execution after loading all your data is to vacuum
the database.  earlier versions of postgres failed to take transaction
commit time into account when computing the visibility of tuples in
concurrent backends.  this has been fixed in 4.0.1.  if you don't vacuum
your database regularly, this will lead to an extra log lookup per tuple
examined.  this may be contributing to the slowdown you're seeing.

					mike olson
					project sequoia 2000
					uc berkeley
					mao@cs.berkeley.edu