Re: Caching by Postgres

From: mark@mark.mielke.cc
Subject: Re: Caching by Postgres
Date: ,
Msg-id: 20050824173055.GA11788@mark.mielke.cc
(view: Whole thread, Raw)
In response to: Re: Caching by Postgres  (Donald Courtney)
Responses: Re: Caching by Postgres  (Alan Stange)
Re: Caching by Postgres  (Thomas Ganss)
List: pgsql-performance

Tree view

Caching by Postgres  (gokulnathbabu manoharan, )
 Re: Caching by Postgres  (John A Meinel, )
  Re: Caching by Postgres  (Josh Berkus, )
 Re: Caching by Postgres  (Bruno Wolff III, )
 Re: Caching by Postgres  (Frank Wiles, )
  Re: Caching by Postgres  (Donald Courtney, )
   Re: Caching by Postgres  (Tom Lane, )
   Re: Caching by Postgres  (Josh Berkus, )
    Re: Caching by Postgres  (Michael Stone, )
   Re: Caching by Postgres  (, )
   Re: Caching by Postgres  (William Yu, )
    Re: Caching by Postgres  (PFC, )
     Re: Caching by Postgres  (Josh Berkus, )
      Re: Caching by Postgres  (PFC, )
     Re: Caching by Postgres  (Gavin Sherry, )
      Re: Caching by Postgres  (Tom Lane, )
       Re: Caching by Postgres  (Gavin Sherry, )
    Re: Caching by Postgres  (Donald Courtney, )
     Re: Caching by Postgres  (Stephen Frost, )
     Re: Caching by Postgres  (, )
      Re: Caching by Postgres  (Alan Stange, )
       Re: Caching by Postgres  (, )
        Re: Caching by Postgres  (Alan Stange, )
         Re: Caching by Postgres  (, )
        Re: Caching by Postgres  (Michael Stone, )
         Re: Caching by Postgres  (, )
       Re: Caching by Postgres  (PFC, )
      Re: Caching by Postgres  (Thomas Ganss, )
     Re: Caching by Postgres  (William Yu, )
 Re: Caching by Postgres  (Chris Browne, )
 Re: Caching by Postgres  (Chris Browne, )

On Wed, Aug 24, 2005 at 09:21:12AM -0400, Donald Courtney wrote:
> I built postgreSQL 8.1 64K bit on solaris 10 a few months ago
> and side by side with the 32 bit postgreSQL build saw no improvement.
> In fact the 64 bit result was slightly lower.

I've had this sort of argument with a friend of mine who works at a
retail computer sales company who always tries to pitch 64-bit
platforms to me (I don't have one yet).

There are a few issues in here that are hard to properly detach to
allow for a fair comparison.

The first, to always remember - is that the move from 64-bits to
32-bits doesn't come for free. In a real 64-bit system with a
64-bit operating system, and 64-bit applications, pointers are
now double their 32-bit size. This means more bytes to copy around
memory, and in an extreme case, has the potential to approach
halfing both the memory latency to access many such pointers from
RAM, and half the effective amount of RAM. In real world cases,
not everything is a pointer, so this sort of performance degradation
is doubtful - but it is something to keep in mind.

In response to this, it appears that, at least on the Intel/AMD side
of things, they've increased the bandwidth on the motherboard, and
allowed for faster memory to be connected to the motherboard. They've
increased the complexity of the chip, to allow 64-bit register
operations to be equivalent in speed to 32-bit register operations.
I have no idea what else they've done... :-)

So, it may be difficult to properly compare a 32-bit system to a
64-bit system. Even if the Ghz on the chip appears equal, it isn't
the same chip, and unless it is the exact same make, product and
version of the motherboard, it may not be a fair compairson. Turning
support for 32-bit on or off, and using a kernel that is only 32-bit
may give good comparisons - but with the above explanation, I would
expect the 32-bit application + kernel to out-perform the 64-bit
application.

So then we move on to what 64-bit is really useful for. Obviously,
there is the arithmetic. If you were previously doing 64-bit
arithmetic through software, you will notice an immediate speed
improvement when doing it through hardware instead. If you have
a program that is scanning memory in any way, it may benefit from
64-bit instructions (for example - copying data 64-bit words at
a time instead of 32-bit words at a time). PostgreSQL might benefit
slightly from either of these, slightly balancing the performance
degradation of using more memory to store the pointers, and more
memory bandwidth the access the pointers.

The real benefit of 64-bit is address space. From the kernel
perspective, it means that more programs, or bigger programs can run
at once. From the application perspective, it means your application
can use more than 32-bits of address space. For programs that make
extensive use of mmap(), this can be a necessity. They are mapping
very large files into their own address space. This isn't a
performance boost, as much as it is a 'you can't do it', if the
files mmap()'ed at the same time, will not fit within 32-bits of
address space. This also becomes, potentially, a performance
degradation, as the system is now having to manage applications
that have very large page tables. Page faults may become
expensive.

PostgreSQL uses read(), instead of mmap(), and uses <2 Gbyte files.
PostgreSQL doesn't require the additional address space for normal
operation.

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.

I've been looking at switching to 64-bit, mostly to benefit from the
better motherboard bandwidth, and just to play around. I'm not
expecting to require the 64-bit instructions.

Hope this helps,
mark

--
 /  /      __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | 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/



pgsql-performance by date:

From: "Jim C. Nasby"
Date:
Subject: Re: Read/Write block sizes
From: mark@mark.mielke.cc
Date:
Subject: Re: Caching by Postgres