Re: [PERFORM] High context switches occurring

2005-11-24 Thread Sven Geisler
e use of the individual or entity to whom they are addressed. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Thank you for your cooperation./ Sven Ge

Re: [PERFORM] Hardware advice

2006-12-05 Thread Sven Geisler
Hi Alexandru, Alexandru Coseru schrieb: > [...] > Question 1: >The RAID layout should be: >a) 2 hdd in raid 1 for system and pg_xlog and 6 hdd in > raid10 for data ? >b) 8 hdd in raid10 for all ? >c) 2 hdd in raid1 for system , 2 hdd in raid1 for pg_xl

[PERFORM] single transaction vs multiple transactions

2006-12-05 Thread Sven Geisler
Hi, I have to refactoring a 'DELETE FROM x WHERE y IN (...)' because IN got to much parameters. => 'stack depth limit exceeded' I don't want to increase just the parameter for max_stack_depth. It is better to refactoring because the number of arguments to IN may increase in the future. My approac

Re: [PERFORM] single transaction vs multiple transactions

2006-12-05 Thread Sven Geisler
Hi Heikki Heikki Linnakangas schrieb: > Sven Geisler wrote: >> I have to refactoring a 'DELETE FROM x WHERE y IN (...)' because IN got >> to much parameters. => 'stack depth limit exceeded' >> I don't want to increase just the parameter for max_st

Re: [PERFORM] single transaction vs multiple transactions

2006-12-05 Thread Sven Geisler
Linnakangas schrieb: > Sven Geisler wrote: >> I have to insert my arguments to a temporary table first, because the >> arguments are only known in the application tier. >> Is a multiple insert to a temporary table and a final 'DELETE FROM x >> WHERE y IN (SELECT z

Re: [PERFORM] Hardware advice

2006-12-06 Thread Sven Geisler
nks for the advices.. > > Actually , i'm waiting for the clovertown to show up on the market... > > Regards > Alex > > - Original Message - > From: "Sven Geisler" <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> &g

Re: [PERFORM] New to PostgreSQL, performance considerations

2006-12-13 Thread Sven Geisler
Hi, Did someone try '-mfpmath=sse -msse3'? Would be interesting to know if -mfpmath=sse boost the performance. I guess, the difference in the generated code isn't that much between i686 and prescott. The bigger step is i386 to i686. '-mfpmath=sse -msse3' will also use the SSE unit, which the cla

Re: [PERFORM] utilising multi-cpu/core machines?

2007-09-07 Thread Sven Geisler
w, are there any documentation about this. > > thomas > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Sven Geisler <[EMAIL PROTECTED]> Tel +49.30.921017.81 Fax .50 Senior Developer, AEC/communications Gmb

Re: [PERFORM] [HACKERS] qsort again

2006-02-16 Thread Sven Geisler
Martijn van Oosterhout schrieb: Last time around there were a number of different algorithms tested. Did anyone run those tests while getting it to count the number of actual comparisons (which could easily swamp the time taken to do the actual sort in some cases)? The last time I did such te

Re: [PERFORM] PostgreSQL and Xeon MP

2006-03-16 Thread Sven Geisler
ded recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. Thank you for your cooperation./ Sven Geisler <[EMAIL PROTECTED]> Tel +49.30.5362.1627 Fax .1638 Senior De

Re: [PERFORM] PostgreSQL and Xeon MP

2006-03-16 Thread Sven Geisler
Hi Guillaume, Guillaume Smet schrieb: The server is a dell 6650 from end of 2004 with 4 xeon mp 2.2 and 2MB cache per proc. Here are the information from Dell: 4x PROCESSOR, 80532, 2.2GHZ, 2MB cache, 400Mhz, SOCKET F 8x DUAL IN-LINE MEMORY MODULE, 512MB, 266MHz You should provide det

Re: [PERFORM] PostgreSQL and Xeon MP

2006-03-16 Thread Sven Geisler
Hi Guillaume, Guillaume Smet schrieb: How much faster is the XEON DP? Well, on high load, PostgreSQL scales well on the DP (load at 40, queries slower but still performing well) and is awfully slow on the MP box. I know what you mean with awfully slow. I think, your application is facing con

Re: [PERFORM] Large (8M) cache vs. dual-core CPUs

2006-04-28 Thread Sven Geisler
Hi all, Vivek Khera schrieb: > On Apr 25, 2006, at 2:14 PM, Bill Moran wrote: >> Where I'm stuck is in deciding whether we want to go with dual-core >> pentiums with 2M cache, or with HT pentiums with 8M cache. > > In order of preference: > > Opterons (dual core or single core) > Xeon with HT *di

Re: [PERFORM] scaling up postgres

2006-06-12 Thread Sven Geisler
contents, but should return it to the sender immediately and delete your copy from your system. Thank you for your cooperation./ Sven Geisler <[EMAIL PROTECTED]> Tel +49.30.5362.1627 Fax .1638 Senior Developer,AEC/communications GmbHBerlin, Germany --

Re: [PERFORM] scaling up postgres

2006-06-12 Thread Sven Geisler
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

Re: [PERFORM] Posrgres speed problem

2006-06-12 Thread Sven Geisler
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

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

2006-06-13 Thread Sven Geisler
Installation of a 32-bit PostgreSQL on a 64-bit Linux like RHEL 4 is very easy. Make sure that you have installed all needed 32-bit libs and devel packages. Here is an example to call configure to get a 32-bit PostgreSQL: CXX="/usr/bin/g++ -m32" \ CPP="/usr/bin/gcc -m32 -E" \ LD="/usr/bin/ld -

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

2006-06-13 Thread Sven Geisler
Luke Luke Lonergan schrieb: On 6/13/06 2:04 AM, "Sven Geisler" <[EMAIL PROTECTED]> wrote: Please find attached a small patch with does apply a change to the x86_64 part also to the i386 part of src/include/storage/s_lock.h. Without this change the performance of PostgreSQL 8.0

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

2006-06-13 Thread Sven Geisler
Luke Luke Lonergan schrieb: Sven, On 6/13/06 5:03 AM, "Sven Geisler" <[EMAIL PROTECTED]> wrote: Yes, I know. We had a problem last year with the performance of the Opteron. We have started the futex patch to resolve the issue. The futex patch itself did have no effect, but

Re: [PERFORM] 64-bit vs 32-bit performance ... backwards?

2006-06-13 Thread Sven Geisler
Luke, Luke Lonergan schrieb: On 6/13/06 5:46 AM, "Sven Geisler" <[EMAIL PROTECTED]> wrote: You already get this change if you compile PostgreSQL 8.1.x in x86_64 (64-bit mode). I see, so I think your point with the patch is to make the 32-bit compiled version benefit as well.

Re: [PERFORM] how to partition disks

2006-06-14 Thread Sven Geisler
Hi Hubert, hubert depesz lubaczewski schrieb: hi i'm waiting for new server to arrive. for the server i will get hp msa1000, with 14 discs (72g, 15000 rpm). what kind of partitioning you suggest, to get maximum performance? for system things i will have separate discs, so whole array is only for

Re: [PERFORM] how to partition disks

2006-06-14 Thread Sven Geisler
Hi Hupert, hubert depesz lubaczewski schrieb: On 6/14/06, *Sven Geisler* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: You should configure your discs to RAID 10 volumes. You should set up a separate volume for WAL. A volume for an additional table space may

Re: [PERFORM] how to partition disks

2006-06-14 Thread Sven Geisler
Hi Richard, Richard Broersma Jr schrieb: This depends on your application. Do you have a lot of disc reads? Anyhow, I would put the xlog always to a RAID 10 volume because most of the I/O for update and inserts is going to the xlog. 4 discs xlog 6 discs tables 4 discs tables2 I have a quest

Re: [PERFORM] Speeding up query, Joining 55mil and 43mil records.

2006-06-21 Thread Sven Geisler
Hi Nicky, I guess, you should try to upgrade the memory setting of PostgreSQL first. work_mem = 65536 Is a bit low for such large joins. Did you get a change to watch the directory /base//pgsql_tmp to see how large the temporary file is during this query. I'm sure that there is large file.

Re: [PERFORM] Speeding up query, Joining 55mil and 43mil records.

2006-06-22 Thread Sven Geisler
Hi Nicky, Did you tried to create an index to avoid the sequential scans? Seq Scan on src_faktuur_verrsec t0... I think, you should try CREATE INDEX src.src_faktuur_verrsec_codesubstr ON src.src_faktuur_verrsec (substr(src.src_faktuur_verrsec.code,1,2)) Cheers Sven. nicky schrieb: Hello a

Re: [PERFORM] Speeding up query, Joining 55mil and 43mil records.

2006-06-22 Thread Sven Geisler
Hi Nick, I'm not that good to advice how to get PostgreSQL to use an index to get your results faster. Did you try "not (substr(t0.code,1,2) in ('14','15','16','17'))"? Cheers Sven. nicky schrieb: Hello Sven, We have the following indexes on src_faktuur_verrsec / CREATE INDEX src_faktu

Re: [HACKERS] [PERFORM] Sun Donated a Sun Fire T2000 to the PostgreSQL

2006-07-21 Thread Sven Geisler
Hi, Tom Lane schrieb: > Robert Lor <[EMAIL PROTECTED]> writes: >> I ran pgbench and fired up a DTrace script using the lwlock probes we've >> added, and it looks like BufMappingLock is the most contended lock, but >> CheckpointStartLocks are held for longer duration! > > Those numbers look a b

Re: [PERFORM] loading increase into huge table with 50.000.000 records

2006-07-26 Thread Sven Geisler
-- /This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you should not copy it, re-transmit it, use it or disclose its contents, but should return it to the s

Re: [PERFORM] Wierd context-switching issue on Xeon

2004-04-20 Thread Sven Geisler
Hi Tom, Just to explain our hardware situation releated to the FSB of the XEON's. We have older XEON DP in operation with FSB 400 and 2.4 GHz. The XEON MP box runs with 2.5 GHz. The XEON MP box is a Fujitsu Siemens Primergy RX600 with ServerWorks GC LE as chipset. The box, which Dirk were use to

Re: [PERFORM] multiple apaches against single postgres database

2007-10-24 Thread Sven Geisler
and have a 1-1 ratio between apache dynamic content > connections and postgres backends. The alternative is to use connection > pooling. Often a combination of the two is best. > -- Sven Geisler <[EMAIL PROTECTED]> Tel +49.30.921017.81 Fax .50 Senior Developer, AEC/communica

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
ave any ideas what my bottle neck might be and what I can > do about it? > > Thanks for any help. > > Matthew. > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Sven Geisler <[EMAIL PROTECTED]&g

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
; like I'll have to look deeper into the connection pooling. > > So you think the problem might be context switching on the server, I'll > take a closer look at the this > > Thanks > > Matthew > > Sven Geisler wrote: >> Hi Matthew, >> >> I

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
as what my bottle neck might be and what I can > do about it? > > Thanks for any help. > > Matthew. > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Sven Geisler <[EMAIL PR

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
e already > had to compile postgres to up the number of function parameters from 32 > to 64. > > Meanwhile I will try and persuade my colleagues to consider the upgrade > option. > > Thanks > Matthew > > Sven Geisler wrote: >> Hi Matthew, >> >> I reme

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
apache/resin combination at the front end, we > have thought about using resin threads to limit the number of > connections but are worried about backing up connections in apache and > getting some overflow here. But some kind of limiting of connections is > probably required. > > Than

Re: [PERFORM] Limited performance on multi core server

2007-12-12 Thread Sven Geisler
t from the spend money. Regards Sven. Matthew Lunnon schrieb: > Hi Sven, > > Does this mean that one option I have is to use a multi core Intel based > server instead of an AMD based server? > > Matthew > > Sven Geisler wrote: >> Hi Matthew, >> >> I remem

Re: [PERFORM] Linux/PostgreSQL scalability issue - problem with 8 cores

2008-01-03 Thread Sven Geisler
lient > applications. > > How can we diagnose what is happening during the peaks? > > ---(end of broadcast)--- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so

Re: [PERFORM] Anyone using a SAN?

2008-02-20 Thread Sven Geisler
buy a SAN and the knowledge from a brand or a specialist company. BTW: You can do other things with SAN you can't do with local disks. - mirroring to another location (room) - mounting snapshots on another server Sven. -- Sven Geisler <[EMAIL PROTECTED]> Tel +49.30.921017.81 Fax