From: mark@mark.mielke.cc
To: Alan Stange <stange@rentec.com>
Cc: Donald Courtney <Donald.Courtney@Sun.COM>
Cc: William Yu <wyu@talisys.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Caching by Postgres
Date: Wed, 24 Aug 2005 15:34:41 -0400
Message-ID: <20050824193441.GA13772@mark.mielke.cc> (raw)
In-Reply-To: <430CC0AD.5040400@rentec.com>
References: <20050823171045.12112.qmail@web51309.mail.yahoo.com>
<20050823124323.710a9dd3.frank@wiles.org>
<430B6DE3.6040109@sun.com>
<deg68k$16gh$1@news.hub.org>
<430C7448.7030103@sun.com>
<20050824173055.GA11788@mark.mielke.cc>
<430CC0AD.5040400@rentec.com>
On Wed, Aug 24, 2005 at 02:47:09PM -0400, Alan Stange wrote:
> At least on Sparc processors, v8 and newer, any double precision math
> (including longs) is performed with a single instruction, just like for
> a 32 bit datum. Loads and stores of 8 byte datums are also handled via
> a single instruction. The urban myth that 64bit math is
> different/better on a 64 bit processor is just that; yes, some lower
> end processors would emulate/trap those instructions but that an
> implementation detail, not architecture.
It isn't an urban myth that 64-bit math on a 64-bit processor is
faster, at least if done using registers. It definately is faster.
It may be an urban myth, though, that most applications perform
a sufficient amount of 64-bit arithmetic to warrant the upgrade.
The benefit may be lost in the noise for an application such as
PostgreSQL. It takes, effectively, infinately longer to access
a disk page, than to increment a 64-bit integer in software.
For the lower end processors that emulate/trap these instructions,
they are being performed in software, along with the overhead of a
trap, and are therefore not a single instruction any more. We are
coming at this from different sides (which is good - perspective is
always good :-) ). From the Intel/AMD side of things, ALL non 64-bit
platforms are 'lower end processors', and don't emulate/trap the
instructions as they didn't exist (at least not yet - who knows what
clever and sufficiently motivated people will do :-) ).
> >If, however, you happen to have a very large amount of physical memory
> >- more memory than is supported by a 32-bit system, but is supported
> >by your 64-bit system, then the operating system should be able to use
> >this additional physical memory to cache file system data pages, which
> >will benefit PostgreSQL if used with tables that are larger than the
> >memory supported by your 32-bit system, and which have queries which
> >require more pages than the memory supported by your 32-bit system to
> >be frequently accessed. If you have a huge database, with many clients
> >accessing the data, this would be a definate yes. With anything less,
> >it is a maybe, or a probably not.
> Solaris, at least, provided support for far more than 4GB of physical
> memory on 32 bit kernels. A newer 64 bit kernel might be more
> efficient, but that's just because the time was taken to support large
> page sizes and more efficient data structures. It's nothing intrinsic
> to a 32 vs 64 bit kernel.
Hehe. That's why I was so careful to qualify my statements. :-)
But yeah, I agree. It's a lot of hype, for not much gain (and some
loss, depending on what it is being used for). I only want one because
they're built better, and because I want to play around.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
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: mark@mark.mielke.cc, stange@rentec.com, Donald.Courtney@Sun.COM, wyu@talisys.com
Subject: Re: Caching by Postgres
In-Reply-To: <20050824193441.GA13772@mark.mielke.cc>
* 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