Skip site navigation (1) Skip section navigation (2)

Re: What's the best hardver for PostgreSQL 8.1?

From: Juan Casero <caseroj(at)comcast(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: What's the best hardver for PostgreSQL 8.1?
Date: 2005-12-23 04:10:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Ok thanks.  I think I will go with 64 bit everything on the box.  If I can get 
the Sun Fire V20Z then I will stick with Solaris 10 x86 and download the 64 
bit PostgreSQL 8.1 binaries from   I develop the PHP code to 
my DSS system on my Windows XP laptop.  Normally, I test the code on this 
laptop but let it hit the live database when I want to run some tests.  Well 
just this afternoon I installed PostgreSQL 8.1.1 on my windows laptop and 
rebuilt the the entire live database instance on there from a pg_dump 
archive.   I am blown away by the performance increase in PostgreSQL 8.1.x.  
Has anyone else had a chance to test it?   All the queries I run against it 
are remarkably fast but more importantly I can see that the two cores of my 
Hyper Threaded P4 are being used.   One of the questions I posted on this 
list was whether PostgreSQL could make use of the large number of cores 
available on the Ultrasparc T1000/T2000 cores.  I am beginning to think that 
with PostgreSQL 8.1.x the buffer manager could indeed use all those cores.  
This could make running a DSS or OLTP on an Ultrasparc T1000/T2000 with 
PostgreSQL a much better bargain than on an intel system.  Any thoughts?


On Thursday 22 December 2005 22:12, David Lang wrote:
> On Wed, 21 Dec 2005, Juan Casero wrote:
> > Date: Wed, 21 Dec 2005 22:31:54 -0500
> > From: Juan Casero <caseroj(at)comcast(dot)net>
> > To: pgsql-performance(at)postgresql(dot)org
> > Subject: Re: [PERFORM] What's the best hardver for PostgreSQL 8.1?
> >
> > Sorry folks.  I had a couple of glasses of wine as I wrote this.  Anyway
> > I originally wanted the box to have more than two drives so I could do
> > RAID 5 but that is going to cost too much.  Also, contrary to my
> > statement below it seems to me I should run the 32 bit postgresql server
> > on the 64 bit kernel. Would you agree this will probably yield the best
> > performance?
> you definantly need a 64 bit kernel to address as much ram as you will
> need.
> the question of 32 bit vs 64 bit postgres needs to be benchmarked, but my
> inclination is that you probably do want 64 bit for that as well.
> 64 bit binaries are slightly larger then 32 bit ones (less so on x86/AMD64
> then on any other mixed platform though), but the 64 bit version also has
> access to twice as many registers as a 32 bit one, and the Opteron chips
> have some other features that become availabel in 64 bit mode (or more
> useful)
> like everything else this needs benchmarks to prove with your workload
> (I'm trying to get some started, but haven't had a chance yet)
> David Lang
> > I know it
> > depends alot on the system but for now this database is about 20
> > gigabytes. Not too large right now but it may grow 5x in the next year.
> >
> > Thanks,
> > Juan
> >
> > On Wednesday 21 December 2005 22:09, Juan Casero wrote:
> >> I just sent my boss an email asking him for a Sun v20z with dual 2.2 Ghz
> >> opterons, 2 Gigs of RAM and RAID 1.  I would have liked a better server
> >> capable of RAID but that seems to be out of his budget right now.  Ok so
> >> I assume I get this Sun box.  Most likely I will go with Linux since it
> >> is a fair bet he doesn't want to pay for the Solaris 10 x86 license. 
> >> Although I kind of like the idea of using Solaris 10 x86 for this.   I
> >> will assume I need to install the x64 kernel that comes with say Fedora
> >> Core 4.  Should I run the Postgresql 8.x binaries in 32 bit mode or 64
> >> bit mode?   My instinct tells me 64 bit mode is most efficient for our
> >> database size about 20 gigs right now but may grow to 100 gigs in a year
> >> or so.  I just finished loading a 20 gig database on a dual 900 Mhz
> >> Ultrasparc III system with 2 gigs of ram and about 768 megs of shared
> >> memory available for the posgresql server running Solaris 10.  The load
> >> has smoked a P4 3.2 Ghz system I am using also with 2 gigs of ram
> >> running postgresql 8.0.3.   I mean I started the sparc load after the P4
> >> load.  The sparc load has finished already rebuilding the database from
> >> a pg_dump file but the P4 system is still going.  The p4 has 1.3 Gigs of
> >> shared memory allocated to postgresql.  How about them apples?
> >>
> >>
> >> Thanks,
> >> Juan
> >>
> >> On Wednesday 21 December 2005 18:57, William Yu wrote:
> >>> Juan Casero wrote:
> >>>> Can you elaborate on the reasons the opteron is better than the Xeon
> >>>> when it comes to disk io?   I have a PostgreSQL 7.4.8 box running a
> >>>> DSS.   One of our
> >>>
> >>> Opterons have 64-bit IOMMU -- Xeons don't. That means in 64-bit mode,
> >>> transfers to > 4GB, the OS must allocated the memory < 4GB, DMA to that
> >>> block and then the CPU must do extra work in copying the memory to >
> >>> 4GB. Versus on the Opteron, it's done by the IO adaptor using DMA in
> >>> the background.
> >>>
> >>> ---------------------------(end of
> >>> broadcast)--------------------------- TIP 6: explain analyze is your
> >>> friend
> >>
> >> ---------------------------(end of broadcast)---------------------------
> >> TIP 1: if posting/reading through Usenet, please send an appropriate
> >>        subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> >>        message can get through to the mailing list cleanly
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: Don't 'kill -9' the postmaster
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

In response to


pgsql-performance by date

Next:From: David LangDate: 2005-12-23 04:14:53
Subject: Re: What's the best hardver for PostgreSQL 8.1?
Previous:From: Greg StarkDate: 2005-12-23 03:52:54
Subject: Re: CPU and RAM

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group