tart = 1))
Total runtime: 81782.052 ms
(18 rows)
---(end of
broadcast)---
TIP 5: don't forget to increase your free space map settings
--
Dirk Lutzebäck <[EMAIL PROTECTED]> Tel +49.30.5362.1635
Fax .1638
CTO AEC/communications GmbH & Co.
KG, Berlin, Germany
Michael Stone wrote:
On Fri, Aug 05, 2005 at 01:11:31PM +0200, Dirk Lutzebäck wrote:
I will compile the latest PostgreSQL 8.1 snapshot for 32bit to
evaluate the new shared buffer code from Tom.
I think, the 64bit is slow because my queries are CPU intensive.
Have you actually tried it or
[[I'm
posting this on behalf of my co-worker who cannot post to this list at
the moment]]
Hi,
I had installed PostgreSQL on a 4-way AMD Opteron 875 (dual core) and
the performance isn't on the expected level.
Details:
The "old" server is a 4-way XEON MP 3.0 GHz with 4MB L3 cache, 32 GB
RA
Hi Jeff,
which box are you running precisely and which OS/kernel?
We need to run 32bit because we need failover to 32 bit XEON system
(DL580). If this does not work out we probably need to switch to 64 bit
(dump/restore) and run a nother 64bit failover box too.
Regards,
Dirk
Jeffrey W. B
Anybody knows if RedHat is already supporting this patch on an
enterprise version?
Regards,
Dirk
J. Andrew Rogers wrote:
On 7/29/05 10:46 AM, "Josh Berkus" wrote:
does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)?
Nope. I suspect that you may be the first
Hi,
does anybody have expierence with this machine (4x 875 dual core Opteron
CPUs)? We run RHEL 3.0, 32bit and under high load it is a drag. We
mostly run memory demanding queries. Context switches are pretty much
around 20.000 on the average, no cs spikes when we run many processes in
parall
Richard Huxton wrote:
Dirk Lutzebäck wrote:
Hi,
I do not under stand the following explain output (pgsql 8.0.3):
explain analyze
select b.e from b, d
where b.r=516081780 and b.c=513652057 and b.e=d.e;
QUERY PLAN
Hi,
I do not under stand the following explain output (pgsql 8.0.3):
explain analyze
select b.e from b, d
where b.r=516081780 and b.c=513652057 and b.e=d.e;
QUERY PLAN
---
Hi,
I would like to start a little survey who is running postgresql on an
8way or more machine (Intel, Sparc, AMD no matter). Purpose: find out
how postgresql runs in high performance areas.
Please fillout:
Machine (Vendor, Product):
Architecture (Intel/Sparc/AMD/IBM):
Processors (Type/Numbe
Hi,
I have a query where I do not understand that the rows number that
explain analyze finds differs so much from what explain estimates (3rd
nested loop estimates 1 row but in real it is 4222 rows). I did analyze
the tables (pgsql 7.4.1).
Here is the query:
explain analyze
SELECT fts.val_1, ma
It is intended to run indefinately.
Dirk
[EMAIL PROTECTED] wrote:
How long is this test supposed to run?
I've launched just 1 for testing, the plan seems horrible; the test is cpu
bound and hasn't finished yet after 17:02 min of CPU time, dual XEON 2.6G
Unixware 713
The machine is a Fujitsu-Sie
Dirk Lutzebaeck wrote:
c) Dual XEON DP, non-bigmem, HT on, E7500 Intel chipset (Supermicro)
performs well and I could not observe context switch peaks here (one
user active), almost no extra semop calls
Did Tom's test here: with 2 processes I'll reach 200k+ CS with peaks to
300k CS. Bummer.. Jo
Josh, I cannot reproduce the excessive semop() on a Dual XEON DP on a
non-bigmem kernel, HT on. Interesting to know if the problem is related
to XEON MP (as Tom wrote) or bigmem.
Josh Berkus wrote:
Dirk,
I'm not sure if this semop() problem is still an issue but the database
behaves a bit
Tom, Josh,
I think we have the problem resolved after I found the following note
from Tom:
> A large number of semops may mean that you have excessive contention
on some lockable
> resource, but I don't have enough info to guess what resource.
This was the key to look at: we were missing all i
Joe, do you know where I should look in the 7.4.2 code to find this out?
Dirk
Joe Conway wrote:
Dirk Lutzebäck wrote:
postgresql 7.4.1
a new Dual Xeon MP
too much context switches (way more than 100.000) on higher load
(meaning system load > 2).
I believe this was fixed in 7.4.2, altho
Hi,
we have a complex modperl database application using postgresql 7.4.1 on
a new Dual Xeon MP Machine with SLES8 which seems to generate too much
context switches (way more than 100.000) on higher load (meaning system
load > 2). System response times significantly slow down then. We have
tun
16 matches
Mail list logo
