Hi Mario,
I did run pgbench on several production servers:
HP DL585 - 4-way AMD Opteron 875
HP DL585 - 4-way AMD Opteron 880
HP DL580 G3 - 4-way Intel XEON MP 3.0 GHz
FSC RX600 S2 - 4-way Intel XEON MP DC 2.66 GHz
FSC RX600 - 4-way Intel XEON MP 2.5 GHz
This test has been done with 8.1.4. I
On 12 Jun 2006, at 00:21, Joshua D. Drake wrote:
Mario Splivalo wrote:
On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote:
On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote:
I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC)
One beast will be apache,
Hi all,
Joshua D. Drake schrieb:
Mario Splivalo wrote:
Could you point out to some more detailed reading on why Xeons are
poorer choice than Opterons when used with PostgreSQL?
It isn't just PostgreSQL. It is any database. Opterons can move memory
and whole lot faster then Xeons.
Yes. You
Hi,
Im having a problem with postgres 8.1.3 on a Fedora Core 3 (kernel
2.6.9-1.667smp)
I have two similar servers, one in production and another for testing
purposes.
Databases are equal (with a difference of some hours)
In the testing server, an sql sentence takes arround 1 sec.
In
Do you run analyze on the production server regularly?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Ruben Rubio Rey
Sent: Monday, June 12, 2006 9:39 AM
To: pgsql-performance@postgresql.org
Subject: [PERFORM] Posrgres speed problem
Hi,
Gábriel Ákos wrote:
Ruben Rubio Rey wrote:
Hi,
Im having a problem with postgres 8.1.3 on a Fedora Core 3 (kernel
2.6.9-1.667smp)
I have two similar servers, one in production and another for testing
purposes.
Databases are equal (with a difference of some hours)
In the testing
Jonah H. Harris wrote:
On 6/12/06, Ruben Rubio Rey [EMAIL PROTECTED] wrote:
I have two similar servers, one in production and another
for testing purposes. In testing server ~1sec ... in
production ~50 secs
What ver of PostgreSQL?
Version 8.1.3
Same ver on both systems?
Yes
Are
On Mon, Jun 12, 2006 at 04:38:57PM +0200, Ruben Rubio Rey wrote:
I have two similar servers, one in production and another for testing
purposes.
Databases are equal (with a difference of some hours)
In the testing server, an sql sentence takes arround 1 sec.
In production server (low
On Mon, Jun 12, 2006 at 11:26:23AM +0530, Gourish Singbal wrote:
Where is the pgsql_tmp folder present ?. i am unable to see it in the data
directory of postgresql.
It will be under the *database* directory, under $PGDATA/base. SELECT
oid,* FROM pg_database; will tell you what directory to
On Mon, Jun 12, 2006 at 04:58:49PM +0200, Ruben Rubio Rey wrote:
$DIREC/vacuumdb -f -v --analyze vacadb 21 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
echo reindex database vacadb; | $DIREC/psql vacadb 21 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
date | $LOGBIN $DIRLOGS/%Y-%m-%d_limpieza.log
Jim C. Nasby wrote:
On Mon, Jun 12, 2006 at 04:58:49PM +0200, Ruben Rubio Rey wrote:
$DIREC/vacuumdb -f -v --analyze vacadb 21 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
echo reindex database vacadb; | $DIREC/psql vacadb 21 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
date | $LOGBIN
On Mon, Jun 12, 2006 at 09:05:06AM -0600, Michael Fuhr wrote:
On Mon, Jun 12, 2006 at 04:38:57PM +0200, Ruben Rubio Rey wrote:
I have two similar servers, one in production and another for testing
purposes.
Databases are equal (with a difference of some hours)
In the testing server,
On Mon, Jun 12, 2006 at 05:22:05PM +0200, Ruben Rubio Rey wrote:
Jim C. Nasby wrote:
On Mon, Jun 12, 2006 at 04:58:49PM +0200, Ruben Rubio Rey wrote:
$DIREC/vacuumdb -f -v --analyze vacadb 21 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
echo reindex database vacadb; | $DIREC/psql vacadb
Here are two ways to phrase a query... the planner choses very different
plans as you will see. Everything is freshly ANALYZEd.
EXPLAIN ANALYZE SELECT r.* FROM raw_annonces r LEFT JOIN annonces a ON
a.id=r.id LEFT JOIN archive_data d ON d.id=r.id WHERE a.id IS NULL AND
d.id IS NULL AND
PFC [EMAIL PROTECTED] writes:
Here are two ways to phrase a query... the planner choses very
different
plans as you will see. Everything is freshly ANALYZEd.
Usually we get complaints the other way around (that the NOT EXISTS
approach is a lot slower). You did not show any
Hi all!
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
Anthony,
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.
I generally see a 20% free gain in performance on 64-bit (Opteron,
Anthony Presley 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
On Jun 12, 2006, at 3:28 PM, Anthony Presley wrote:
Hi all!
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
Anthony Presley [EMAIL PROTECTED] writes:
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
* Anthony Presley ([EMAIL PROTECTED]) 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
Anthony Presley [EMAIL PROTECTED] wrote:
Hi all!
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
Empirically... postgresql built for 64 bits is marginally slower than
that built
for a 32 bit api on sparc. None of my customers have found 64 bit x86
systems to be suitable for production use, yet, so I've not tested on any
of those architectures.
Really? All of our customers are migrating
On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote:
Empirically... postgresql built for 64 bits is marginally slower
than that built
for a 32 bit api on sparc. None of my customers have found 64 bit x86
systems to be suitable for production use, yet, so I've not tested
on any
of those
Title: Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?
Opteron is ~20% faster at executing code in 64-bit mode than 32-bit because of the extra registers made available with their 64-bit mode:
http://www.tomshardware.com/2003/04/22/duel_of_the_titans/page7.html
Doubling the GPRs
I've been trying to track this stuff - in fact, I'll likely be
switching from AMD32 to AMD64 in the next few weeks.
I believe I have a handle on the + vs - of 64-bit. It makes sense that
full 64-bit would be slower. At an extreme it halfs the amount of
available memory or doubles the required
Anyone who has tried x86-64 linux knows what a royal pain in the ass it is. They didn't do anything sensible, like just make the whole OS 64 bit, no, they had to split it up, and put 64-bit libs in a new directory /lib64. This means that a great many applications don't know to check in there for
[EMAIL PROTECTED] (Anthony Presley) wrote:
Hi all!
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
Alex Turner [EMAIL PROTECTED] writes:
Anyone who has tried x86-64 linux knows what a royal pain in the ass it
is. They didn't do anything sensible, like just make the whole OS 64 bit,
no, they had to split it up, and put 64-bit libs in a new directory /lib64.
Actually, there's nothing wrong
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Alex Turner)
wrote:
Anyone who has tried x86-64 linux knows what a royal pain in the ass
it is. They didn't do anything sensible, like just make the whole
OS 64 bit, no, they had to split it up, and put 64-bit libs in a new
Mark,
On 6/12/06 7:16 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I haven't. I'm meaning to take a look. Within registers, 64-bit should
be equal speed to 32-bit. Outside the registers, it would make sense
to only deal with the lower 32-bits where 32-bits is all that is
required.
The
On Jun 12, 2006, at 19:44, Tom Lane wrote:
(Personally, if I'd designed it, the libraries would actually live in
/usr/lib32 and /usr/lib64, and /usr/lib would be a symlink to
whichever
you needed it to be at the moment. Likewise for /usr/bin.)
/me nominates Tom to create a Linux
Alex Turner wrote:
Anyone who has tried x86-64 linux knows what a royal pain in the ass it
is. They didn't do anything sensible, like just make the whole OS 64
bit, no, they had to split it up, and put 64-bit libs in a new directory
/lib64. This means that a great many applications don't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sven Geisler wrote:
Hi Mario,
I did run pgbench on several production servers:
HP DL585 - 4-way AMD Opteron 875
HP DL585 - 4-way AMD Opteron 880
HP DL580 G3 - 4-way Intel XEON MP 3.0 GHz
FSC RX600 S2 - 4-way Intel XEON MP DC 2.66 GHz
FSC
Folks,
FWIW, the applications where I did direct 32 / 64 comparison were
a) several data warehouse tests, with databases 100GB
b) computation-heavy applications (such as a complex calendaring app)
And, as others have pointed out, I wasn't comparing generics; I was comparing
Athalon/Xeon to
35 matches
Mail list logo
