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
Great discussion and illuminating for those of us who are still
learning the subtleties of postGres.
William
To be clear -
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
* Donald Courtney ([EMAIL PROTECTED]) wrote:
To be clear -
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.
That makes some sense actually. It really depends on
Really? Cool, I'd like to see that. Could you follow up with Hans?
Or give
me his e-mail?
You can subscribe to the Reiser mailinglist on namesys.com or :
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: if posting/reading
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
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'm not surprised 32-bit binaries running on a 64-bit OS would be faster
than
[EMAIL PROTECTED] wrote:
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
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
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
On Wed, Aug 24, 2005 at 03:34:41PM -0400, [EMAIL PROTECTED] wrote:
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
On Wed, Aug 24, 2005 at 05:09:04PM -0400, Alan Stange wrote:
The older 32bit RISC processors do have 64 bit registers, ALUs and
datapaths, and they are marketed toward high end scientific computing,
and you're claiming that such a processor is slower than one which has
the addition of 64
gokulnathbabu manoharan wrote:
Hi all,
I like to know the caching policies of Postgresql.
What parameter in the postgresql.conf affects the
cache size used by the Postgresql? As far as I have
searched my knowledge of the parameters are
In general, you don't. The OS handles caching based on
John,
So I'm guessing that with 8.1 there would be 2 sweet spots. Low
shared_buffers (= 10k), and really high shared buffers (like all of
available ram).
But because postgres has been tuned for the former I would stick with it
(I don't think shared_buffers can go 2GB, but that might just be
On Tue, Aug 23, 2005 at 10:10:45 -0700,
gokulnathbabu manoharan [EMAIL PROTECTED] wrote:
Hi all,
I like to know the caching policies of Postgresql.
What parameter in the postgresql.conf affects the
cache size used by the Postgresql? As far as I have
searched my knowledge of the
I mean well with this comment -
This whole issue of data caching is a troubling issue with postreSQL
in that even if you ran postgreSQL on a 64 bit address space
with larger number of CPUs you won't see much of a scale up
and possibly even a drop. I am not alone in having the *expectation*
Donald,
This whole issue of data caching is a troubling issue with postreSQL
in that even if you ran postgreSQL on a 64 bit address space
with larger number of CPUs you won't see much of a scale up
and possibly even a drop.
Since when? Barring the context switch bug, you're not going to
On Tue, Aug 23, 2005 at 02:41:39PM -0400, Donald Courtney wrote:
I mean well with this comment -
This whole issue of data caching is a troubling issue with postreSQL
in that even if you ran postgreSQL on a 64 bit address space
with larger number of CPUs you won't see much of a scale up
and
On Tue, Aug 23, 2005 at 12:38:04PM -0700, Josh Berkus wrote:
which have a clear and measurable effect on performance and are fixable
without bloating the PG code. Some of these issues (COPY path, context
switching
Does that include increasing the size of read/write blocks? I've noticed
that
[EMAIL PROTECTED] (Donald Courtney) writes:
I mean well with this comment -
This whole issue of data caching is a troubling issue with postreSQL
in that even if you ran postgreSQL on a 64 bit address space
with larger number of CPUs you won't see much of a scale up
and possibly even a drop.
[EMAIL PROTECTED] (Michael Stone) writes:
On Tue, Aug 23, 2005 at 12:38:04PM -0700, Josh Berkus wrote:
which have a clear and measurable effect on performance and are
fixable without bloating the PG code. Some of these issues (COPY
path, context switching
Does that include increasing the
Donald Courtney wrote:
in that even if you ran postgreSQL on a 64 bit address space
with larger number of CPUs you won't see much of a scale up
and possibly even a drop. I am not alone in having the *expectation*
What's your basis for believing this is the case? Why would PostgreSQL's
Josh Berkus has already mentioned this as conventional wisdom as written
by Oracle. This may also be legacy wisdom. Oracle/Sybase/etc has been
around for a long time; it was probably a clear performance win way back
when. Nowadays with how far open-source OS's have advanced, I'd take it
PFC,
Now, Hans Reiser has expressed interest on the ReiserFS list in
tweaking his Reiser4 especially for Postgres. In his own words, he wants
a Killer app for reiser4. Reiser4 will offser transactional semantics via
a special reiser4 syscall, so it might be possible, with a minimum
On Wed, 24 Aug 2005, PFC wrote:
Josh Berkus has already mentioned this as conventional wisdom as written
by Oracle. This may also be legacy wisdom. Oracle/Sybase/etc has been
around for a long time; it was probably a clear performance win way back
when. Nowadays with how far open-source
Gavin Sherry [EMAIL PROTECTED] writes:
A filesystem could, in theory, help us by providing an API which allows us
to tell the file system either: the way we'd like it to read ahead, the
fact that we don't want it to read ahead or the way we'd like it to cache
(or not cache) data. The thing is,
On Wed, 24 Aug 2005, Tom Lane wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
A filesystem could, in theory, help us by providing an API which allows us
to tell the file system either: the way we'd like it to read ahead, the
fact that we don't want it to read ahead or the way we'd like it to
26 matches
Mail list logo
