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
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
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 arit
[EMAIL PROTECTED] wrote:
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 hand
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 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 inst
[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 i
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 64-bit/64-bit.
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
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
* 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 o
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 slightly
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 li
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 thin
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
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 min
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
w
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
depend
[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 increasin
[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 dr
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 w
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
>
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
Donald Courtney <[EMAIL PROTECTED]> writes:
> I am not alone in having the *expectation* that a database should have
> some cache size parameter and the option to skip the file system. If
> I use oracle, sybase, mysql and maxdb they all have the ability to
> size a data cache and move to 64 bits.
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*
t
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 p
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 ju
On Tue, 23 Aug 2005 10:10:45 -0700 (PDT)
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 p
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 bas
29 matches
Mail list logo
