Date: Thu, 7 Jan 2010 21:02:58 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Gary Warner <gar@cis.uab.edu>
Cc: pgsql-performance@postgresql.org
Subject: Re: "large" spam tables and performance: postgres memory
	parameters
Message-ID: <20100108020258.GG17756@tamriel.snowman.net>
References: <950265612.141041.1262877637416.JavaMail.root@zimbra.cis.uab.edu>
	<1370423997.141099.1262877797658.JavaMail.root@zimbra.cis.uab.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="wt7c5SQqKurwN+I7"
Content-Disposition: inline
In-Reply-To: 
 <1370423997.141099.1262877797658.JavaMail.root@zimbra.cis.uab.edu>
User-Agent: Mutt/1.5.18 (2008-05-17)


--wt7c5SQqKurwN+I7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Gary Warner (gar@cis.uab.edu) wrote:
>  - if you have 8 pentium cores, 12GB of RAM and "infinite" diskspace, wha=
t sorts of memory settings would you have in your start up tables?

If the PG database is the only thing on the system, I'd probably go with
something like:

shared_buffers =3D 4GB
temp_buffers =3D 1GB
work_mem =3D 128M # Maybe adjust this during a session if you have
                # big/complex queries
maintenance_work_mem =3D 256M
checkpoint_segments =3D 20 # Maybe more..
effective_cache_size =3D 8GB # Maybe more if you have a SAN which is doing
                           # cacheing for you too..


>   My biggest question mark there really has to do with how many users I h=
ave and how that might alter the results. =20

Presuming what you mean by this is "how would the number of users change
the settings I'm suggesting above", I'd say "probably not much for the
number of users you're talking about.".  Really, 12-25 users just isn't
all that many.  You probably need a queueing system to handle requests
that are going to take a long time to complete (as in, don't expect the
user or their web browser to stick around while you run a query that
takes half an hour to complete...).

> (I'll let this thread run a bit, and then come back to ask questions abou=
t "vacuum analyze" and "partitioned tables" as a second and third round of =
questions.)=20

You should definitely be lookig to do partitioning based on the type of
data and the way you want to restrict the queries.  I'm not convinced
you'd actually *need* to restrict the queries to recent things if you
partition correctly- you might restrict the total *range* to be
something small enough that it won't take too long.

It sounds like you have a number of systems, in which case you might
consider sharding if you get a large number of users (where large is a
whole lot bigger than 25...) or you find that users really do need
real-time results on very large ranges.  It involves a fair bit of code
to do and do well though, so you really have to consider it carefully
and make sure it will help your important use cases (and not too badly
impact your other use cases) before going that route.

autovacuum is your friend..  though you might need to tune it.

	Thanks,

		Stephen

--wt7c5SQqKurwN+I7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktGklIACgkQrzgMPqB3kigsVQCgjtu05Udon65FPuODzzRfjDcR
d2kAmgM1mF9nxaMlKeiAIBBfKXPwpSwj
=YLch
-----END PGP SIGNATURE-----

--wt7c5SQqKurwN+I7--