Tonight database has been vacumm full and reindex (all nights database
do it)
Now its working fine. Speed is as spected. I ll be watching that sql ...
Maybe the problem exists when database is busy, or maybe its solved ...
---(end of broadcast)---
Jim C. Nasby wrote:
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
On Mon, Jun 12, 2006 at 10:44:01PM -0400, 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.)
Actually, there have been plans
Greg Stark wrote:
However that's not enough to explain what you've shown. How about you show the
actual query and actual plan you're working with? The plan you've shown can't
result from the query you sent.
Mea culpa, sort of. But ... in fact, the plan I sent *was* from query I sent, with the
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 Op
-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
> F
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 kno
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 distributi
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.
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
>
"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
[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 t
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
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 memo
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 fr
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 ar
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 t
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
* 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 32
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-
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 SLO
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 gu
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 (Opte
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 Pos
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 statis
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
Hi Ruben,
Ruben Rubio Rey schrieb:
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 se
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 2>&1 | $LOGBIN
> >>$DIRLOGS/%Y-%m-%d_limpieza.log
> >>echo "reindex database vacadb;" |
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
Jim C. Nasby wrote:
On Mon, Jun 12, 2006 at 04:58:49PM +0200, Ruben Rubio Rey wrote:
$DIREC/vacuumdb -f -v --analyze vacadb 2>&1 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
echo "reindex database vacadb;" | $DIREC/psql vacadb 2>&1 | $LOGBIN
$DIRLOGS/%Y-%m-%d_limpieza.log
date | $LOGBIN $DIRLO
On Mon, Jun 12, 2006 at 04:58:49PM +0200, Ruben Rubio Rey wrote:
> $DIREC/vacuumdb -f -v --analyze vacadb 2>&1 | $LOGBIN
> $DIRLOGS/%Y-%m-%d_limpieza.log
> echo "reindex database vacadb;" | $DIREC/psql vacadb 2>&1 | $LOGBIN
> $DIRLOGS/%Y-%m-%d_limpieza.log
> date | $LOGBIN $DIRLOGS/%Y-%m-%d_limpi
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 lo
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
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
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 server,
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,
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 produc
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
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, an
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 incr
40 matches
Mail list logo