pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Stephen Frost <sfrost@snowman.net>
To: Anthony Presley <anthony@resolution.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Date: Mon, 12 Jun 2006 20:04:41 -0400
Message-ID: <20060613000441.GI8588@kenobi.snowman.net> (raw)
In-Reply-To: <1150151282.14661.42.camel@tigger>
References: <1150151282.14661.42.camel@tigger>

* Anthony Presley (anthony@resolution.com) wrote:
> I had an interesting discussion today w/ an Enterprise DB developer and
> sales person, and was told, twice, that the 64-bit linux version of
> Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1)
> is SIGNIFICANTLY SLOWER than the 32-bit version.  Since the guys of EDB
> are PostgreSQL ..... has anyone seen that the 64-bit is slower than the
> 32-bit version?

Alot of it depends on what you're doing in the database, exactly, and
just which 32/64-bit platform is under discussion..  They're not all the
same (not even just amoung the ones Linux runs on :).

> I was told that the added 32-bits puts a "strain" and extra "overhead"
> on the processor / etc.... which actually slows down the pointers and
> necessary back-end "stuff" on the database.

That's so hand-wavy that I'd be disinclined to believe the speaker, so
I'll assume you're (poorly) paraphrasing...  It's true that running
64bit means that you've got 64bit pointers, which are physically
larger than 32bit pointers.  Larger pointers means more effort to keep
track of them, copy them around, etc.  This is mitigated on some
platforms (ie: amd64) where there are extra registers available in
'64bit' mode (which is really more than just a 64bit mode of a 32bit
platform, unlike a platform like PPC or sparc).

> I'm curious if anyone can back this up .... or debunk it.  It's about
> the polar opposite of everything I've heard from every other database
> vendor for the past several years, and would be quite an eye-opener for
> me.

PostgreSQL doesn't generally operate on >2G resident memory.  I'm not
sure if it's possible for it to (I havn't really tried to find out,
though I have systems where it'd be possible to want to sort a >2G table
or similar, I don't have the work_mem set high enough for it to try, I
don't think).  This is because Postgres lets the OS handle most of the
cacheing, so as long as your OS can see all the memory you have in the
box, that benefit of running 64bit isn't going to be seen on Postgres.
On many other database systems (notably the 800-pound gorillas...) the
database handle the cacheing and so wants to basically have control over
all the memory in the box, which means running 64bit if you have more
than 2G in your system.

Just my 2c.

	Enjoy,

		Stephen

Attachments:

  signature.asc (application/pgp-signature, 188B) download

view thread (34+ messages)  latest in thread

Message-ID: <20060613000441.GI8588@kenobi.snowman.net>
Permalink:  ../20060613000441.GI8588@kenobi.snowman.net/
Also on:    postgresql.org/message-id/20060613000441.GI8588@kenobi.snowman.net

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: sfrost@snowman.net, anthony@resolution.com
  Subject: Re: 64-bit vs 32-bit performance ... backwards?
  In-Reply-To: <20060613000441.GI8588@kenobi.snowman.net>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox