Re: [PERFORM] Hardware questions

Junaili, I'd suggest you don't buy a dell. The aren't particularly good performers. Dave Junaili Lie wrote: Hi guys, We are in the process of buying a new dell server. Here is what we need to be able to do: - we need to be able to do queries on tables that has 10-20 millions of records (around 40-6

Re: [PERFORM] How to improve db performance with $7K?

0m4.162s user0m0.020s sys 0m0.510s (the file was not in the cache) => about 52 MB/s (reiser3.6) So, you have a problem with your hardware... ---(end of broadcast)--- TIP 7: don't forget to increase your free space

Re: [PERFORM] How to improve db performance with $7K?

Yeah, 35Mb per sec is slow for a raid controller, the 3ware mirrored is about 50Mb/sec, and striped is about 100 Dave PFC wrote: With hardware tuning, I am sure we can do better than 35Mb per sec. Also WTF ? My Laptop does 19 MB/s (reading <10 KB files, reiser4) ! A recent desktop 7

Re: [PERFORM] batch inserts are "slow"

3 May 2005, Josh Berkus wrote: There are several hacks floating around that add COPY capabilities to the pgjdbc driver. As they all are rather simple hacks, they have not been included in the cvs yet, but they tend to work fine. FWIW, Dave Cramer just added beta COPY capability to JDBC. C

Re: [PERFORM] Performance Tuning Article

you search the archives for xeon sooner or later you will bump into something relevant. -- Kind Regards, Keith ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings Dave Cramer [EMAIL PROTECTED] www.postg

Re: [PERFORM] Performance Tuning Article

AFAIK, the problem was the buffer manager Dave On 23-Jun-05, at 9:46 AM, Radu-Adrian Popescu wrote: Dave Cramer wrote: My understanding is that it isn't particularly XEON processors that is the problem Any dual processor will exhibit the problem, XEON's with hyperthreading

Re: [PERFORM] [JDBC] Performance problem using V3 protocol in jdbc driver

Barry, One way to do this is to turn logging on for calls over a certain duration log_duration in the config file. This will only log calls over n milliseconds. There's a tool called iron eye SQL that monitors JDBC calls. http://www.irongrid.com/ unfortunately I am getting DNS errors

Re: [PERFORM] Prepared statement not using index

The difference between the 7.4 driver and the 8.0.3 driver is the 8.0.3 driver is using server side prepared statements and binding the parameter to the type in setXXX(n,val). The 7.4 driver just replaces the ? with the value and doesn't use server side prepared statements. Dave On 1-Se

Re: [PERFORM] Prepared statement not using index

On 12-Sep-05, at 9:22 AM, Guido Neitzer wrote: On 12.09.2005, at 14:38 Uhr, Dave Cramer wrote: The difference between the 7.4 driver and the 8.0.3 driver is the 8.0.3 driver is using server side prepared statements and binding the parameter to the type in setXXX(n,val). Would be a

Re: [PERFORM] Prepared statement not using index

It's added, just use the old protocol . Here are the connection parameters http://jdbc.postgresql.org/documentation/head/connect.html#connection- parameters Dave On 12-Sep-05, at 9:26 AM, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The difference between

Re: [PERFORM] How to determine cause of performance problem?

Joost, I presume you are using a relatively new jdbc driver. Make sure you have added prepareThreshold=1 to the url to that it will use a named server side prepared statement You could also use your mod 100 code block to implement batch processing of the inserts. see addBatch, in jdbc

Re: [PERFORM] Advice on RAID card

I would think software raid would be quite inappropriate considering postgres when it is working is taking a fair amount of CPU as would software RAID. Does anyone know if this is really the case ? Dave On 25-Sep-05, at 6:17 AM, Michael Ben-Nes wrote: I would consider Software Raid PFC wr

Re: [PERFORM] Performance PG 8.0 on dual opteron / 4GB / 3ware Raid5 / Debian??

Joost, I've got experience with these controllers and which version do you have. I'd expect to see higher than 50MB/s although I've never tried RAID 5 I routinely see closer to 100MB/s with RAID 1+0 on their 9000 series I would also suggest that shared buffers should be higher than 7500,

Re: [PERFORM] Hardware/OS recommendations for large databases (

Luke,Have you tried the areca cards, they are slightly faster yet.DaveOn 15-Nov-05, at 7:09 AM, Luke Lonergan wrote: I agree - you can get a very good one from www.acmemicro.com or www.rackable.com with 8x 400GB SATA disks and the new 3Ware 9550SX SATA RAID controller for about $6K with two Opteron

Re: [PERFORM] Hardware/OS recommendations for large databases (

On 17-Nov-05, at 2:50 PM, Alex Turner wrote: Just pick up a SCSI drive and a consumer ATA drive. Feel their weight. You don't have to look inside to tell the difference. At one point stereo manufacturers put weights in the case just to make them heavier. The older ones weighed more and the

Re: [PERFORM] Hardware/OS recommendations for large databases (

On 18-Nov-05, at 1:07 AM, Luke Lonergan wrote: Greg, On 11/17/05 9:17 PM, "Greg Stark" <[EMAIL PROTECTED]> wrote: Ok, a more productive point: it's not really the size of the database that controls whether you're I/O bound or CPU bound. It's the available I/O bandwidth versus your CPU s

Re: [PERFORM] Hardware/OS recommendations for large databases (

On 18-Nov-05, at 8:30 AM, Luke Lonergan wrote: Richard, On 11/18/05 5:22 AM, "Richard Huxton" wrote: Well, I'm prepared to swap Luke *TWO* $1000 systems for one $80,000 system if he's got one going :-) Finally, a game worth playing! Except it’s backward – I’ll show you 80 $1,

Re: [PERFORM] Hardware/OS recommendations for large databases (

Luke,Interesting numbers. I'm a little concerned about the use of blockdev —setra 16384. If I understand this correctly it assumes that the table is contiguous on the disk does it not ?DaveOn 18-Nov-05, at 10:13 AM, Luke Lonergan wrote: Dave, On 11/18/05 5:00 AM, "Dave Cramer" &l

Re: [PERFORM] Hyperthreading slows processes?

Yeah, it's pretty much a known issue for postgres Dave On 20-Nov-05, at 4:46 PM, Craig A. James wrote: This article on ZDNet claims that hyperthreading can *hurt* performance, due to contention in the L1/L2 cache by a second process: http://news.zdnet.co.uk/0,39020330,39237341,00.htm Has

Re: [PERFORM] effizient query with jdbc

The problem is you are getting the entire list back at once. You may want to try using a cursor. Dave On 15-Dec-05, at 9:44 AM, [EMAIL PROTECTED] wrote: Hi, I have a java.util.List of values (1) which i wanted to use for a query in the where clause of an simple select statement. iterat

Re: [PERFORM] Configuration settings for 32GB RAM server

On 4-Dec-06, at 12:10 PM, Mark Lonsdale wrote: Hi We are migrating our Postgres 7.3.4 application to postgres 8.1.5 and also moving it to a server with a much larger hardware configuration as well.The server will have the following specification. - 4 physical CPUs (hypert

Re: [PERFORM] Locking in PostgreSQL?

Unless you specifically ask for it postgresql doesn't lock any rows when you update data. Dave On 6-Dec-06, at 2:04 AM, Joost Kraaijeveld wrote: Does PostgreSQL lock the entire row in a table if I update only 1 column? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nij

Re: [PERFORM] Locking in PostgreSQL?

On 6-Dec-06, at 8:20 AM, Jens Schipkowski wrote: On Wed, 06 Dec 2006 13:29:37 +0100, Dave Cramer <[EMAIL PROTECTED]> wrote: Unless you specifically ask for it postgresql doesn't lock any rows when you update data. Thats not right. UPDATE will force a RowExclusiveLock to rows

Re: [PERFORM] New to PostgreSQL, performance considerations

On 11-Dec-06, at 5:36 AM, Daniel van Ham Colchete wrote: Hi Dave, On 12/11/06, Dave Cramer <[EMAIL PROTECTED]> wrote: Hi Daniel On 10-Dec-06, at 8:02 PM, Daniel van Ham Colchete wrote: > Hi Gene, > > at my postgresql.conf, the only non-comented lines are: > fsync = off

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

Guy, Did you tune postgresql ? How much memory does the box have? Have you tuned postgresql ? Dave On 28-Dec-06, at 12:46 AM, Guy Rouillier wrote: I don't want to violate any license agreement by discussing performance, so I'll refer to a large, commercial PostgreSQL- compatible DBMS only

Re: [PERFORM] Postgresql Configutation and overflow

Hi, On 28-Dec-06, at 8:58 PM, fabrix peñuelas wrote: Good day, I have been reading about the configuration of postgresql, but I have a server who does not give me the performance that should. The tables are indexed and made vacuum regularly, i monitor with top, ps and pg_stat_activity an

Re: [PERFORM] Worse perfomance on 8.2.0 than on 7.4.14

On 31-Dec-06, at 6:33 AM, Rolf Østvik wrote: Hi I have a simple query which uses 32ms on 7.4.14 and 1015ms on 8.2.0. I guess 7.4.14 creates a better execution plan than 8.2.0 for this query but i don't know how to get it to select a better one. Explain analyse output will be found near the

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

On 5-Jan-07, at 9:51 PM, Guy Rouillier wrote: I've got back access to my test system. I ran another test run with the same input data set. This time I put pg_xlog on a different RAID volume (the unused one that I suspect is a software RAID), and I turned fsync=off in postgresql.conf. I

Re: [PERFORM] High update activity, PostgreSQL vs BigDBMS

On 6-Jan-07, at 11:32 PM, Guy Rouillier wrote: Dave Cramer wrote: The box has 3 GB of memory. I would think that BigDBMS would be hurt by this more than PG. Here are the settings I've modified in postgresql.conf: As I said you need to set shared_buffers to at least 750MB this is

Re: [PERFORM] Horribly slow query/ sequential scan

On 9-Jan-07, at 7:50 AM, Nörder-Tuitje, Marcus wrote: Forget abount "IN". Its horribly slow. I think that statement above was historically correct, but is now incorrect. IN has been optimized quite significantly since 7.4 Dave try : select w.appid, w.rate, w.is_subscribe

Re: [PERFORM] Large table performance

On 12-Jan-07, at 7:31 PM, Mark Dobbrow wrote: Hello - I have a fairly large table (3 million records), and am fetching 10,000 non-contigous records doing a simple select on an indexed column ie select grades from large_table where teacher_id = X This is a test database, so the number of

Re: [PERFORM] Performance of Parser?

On 13-Jan-07, at 7:24 PM, Tom Lane wrote: Jignesh Shah <[EMAIL PROTECTED]> writes: The appserver is basically using bunch of prepared statements that the server should be executing directly without doing the parsing again. Better have another look at that theory, because you're clearly s

Re: [PERFORM]

On 14-Jan-07, at 7:31 AM, Rolf Østvik (HA/EXA) wrote: 1234567890123456789012345678901234567890123456789012345678901234567890 1234567890 00112233445566 77 I have been trying to change a many parameters on server versions 7.4.15, 8

Re: [PERFORM] Problem with grouping, uses Sort and GroupAggregate, HashAggregate is better(?)

On 14-Jan-07, at 10:34 AM, Rolf Østvik (HA/EXA) wrote: Computer: Dell PowerEdge 2950 openSUSE Linux 10.1 Intel(R) Xeon 3.00GHz 4GB memory xfs filesystem on SAS disks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf

Re: [PERFORM] PG8.2.1 choosing slow seqscan over idx scan

On 17-Jan-07, at 9:37 AM, Jeremy Haile wrote: I still keep wondering if this table is bloated with dead tuples. Even if you vacuum often if there's a connection with an idle transaction, the tuples can't be reclaimed and the table would continue to grow. I used to vacuum once an hour, alth

Re: [PERFORM] Configuration Advice

On 17-Jan-07, at 3:41 PM, Steve wrote: Hey there; I've been lurking on this list awhile, and I've been working with postgres for a number of years so I'm not exactly new to this. But I'm still having trouble getting a good balance of settings and I'd like to see what other people think.

Re: [PERFORM] Tuning

On 26-Jan-07, at 6:28 AM, John Parnefjord wrote: Hi! I'm planning to move from mysql to postgresql as I believe the latter performs better when it comes to complex queries. The mysql database that I'm running is about 150 GB in size, with 300 million rows in the largest table. We do quite a l

Re: [PERFORM] [JDBC] does prepareThreshold work? forced to use old driver

On 26-Feb-07, at 11:12 AM, Gene wrote: hi! I've been having some serious performance issues with postgresql8.2/hibernate/jdbc due to postgres reusing bad cached query plans. It doesn't look at the parameter values and therefore does not use any partial indexes. After trying to set prepareThre

Re: [PERFORM] SATA RAID: Promise vs. 3ware

On 20-Mar-07, at 9:23 AM, Ireneusz Pluta wrote: Hello all, I sent a similar post to a FreeBSD group, but thought I'd might try here too. I am completing a box for PostgreSQL server on FreeBSD. Selecting a RAID controller I decided to go with 3ware SE9650-16, following good opinions abo

Re: [PERFORM] SATA RAID: Promise vs. 3ware

On 20-Mar-07, at 1:53 PM, Benjamin Arai wrote: This is a little biased but I would stay away from areca only because they have fans on the card. At some point down the line that card is going to die. When it does there is really no telling what it will do to your data. I personally use

Re: [PERFORM] Optimization postgresql 8.1.4 FC 6 X64 ?

I also think there have been changes in pgbench itself. Make sure you run the same pgbench on both servers. Dave On 24-Mar-07, at 6:44 AM, Heikki Linnakangas wrote: amrit angsusingh wrote: I try to change my database server from the older one ie. 2Cpu Xeon 2.4 32 bit 4Gb SDram Hdd SCSI RAID

Re: [PERFORM] scalablility problem

I may have missed this but have you tuned your postgresql configuration ? 8.2 tuning guidelines are significantly different than 7.3 Dave On 1-Apr-07, at 1:51 PM, Xiaoning Ding wrote: I repeated the test again. It took 0.92 second under 8.2.3. I checked system load using top and ps. There i

Re: [PERFORM] Scaling SELECT:s with the number of disks on a stripe

On 4-Apr-07, at 2:01 AM, Peter Schuller wrote: Hello, The next question then is whether anything in your postgres configuration is preventing it getting useful performance from the OS. What settings have you changed in postgresql.conf? The only options not commented out are the followin

Re: [PERFORM] High Load on Postgres 7.4.16 Server

On 5-Apr-07, at 3:33 PM, John Allgood wrote: The hard thing about running multiple postmasters is that you have to tune each one separate. Most of the databases I have limited the max- connections to 30-50 depending on the database. What would reasonable values for effective_cache_size and r

Re: [PERFORM] High Load on Postgres 7.4.16 Server

TECTED] On Behalf Of Dave Cramer Sent: Thursday, April 05, 2007 4:01 PM To: John Allgood Cc: 'Jeff Frost'; pgsql-performance@postgresql.org Subject: Re: [PERFORM] High Load on Postgres 7.4.16 Server On 5-Apr-07, at 3:33 PM, John Allgood wrote: The hard thing about running multiple pos

Re: [PERFORM] Foreign Key Deadlocking

Hi Csaba, I have a similar problem. In an attempt to avoid the overhead of select count(*) from mailbox where uid = somuid I've implemented triggers on insert and delete. So there is a user table which refers to to an inbox table, so when people insert into the inbox there is an RI trigger

Re: [PERFORM] What`s wrong with JFS configuration?

On 25-Apr-07, at 4:54 AM, Heikki Linnakangas wrote: Paweł Gruszczyński wrote: To test I use pgBench with default database schema, run for 25, 50, 75 users at one time. Every test I run 5 time to take average. Unfortunetly my result shows that ext is fastest, ext3 and jfs are very simillar.

Re: [PERFORM] Intermitent slow queries

On 2-May-07, at 11:24 AM, Parks, Aaron B. wrote: My pg 8.1 install on an AMD-64 box (4 processors) with 9 gigs of ram running RHEL4 is acting kind of odd and I thought I would see if anybody has any hints. I have Java program using postgresql-8.1-409.jdbc3.jar to connect over the netwo

Re: [PERFORM] 500 requests per second

* set reasonable statement timeout * backup with pitr. pg_dump is a headache on extremely busy servers. Where do you put your pitr wal logs so that they don't take up extra I/O ? * get good i/o system for your box. start with 6 disk raid 10 and go from there. * spend some time reading about

[PERFORM] PITR performance costs

Since PITR has to enable archiving does this not increase the amount of disk I/O required ? Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] PITR performance costs

Heikki, Don't the archived logs have to be copied as well as the regular WAL logs get recycled ? Dave On 28-May-07, at 12:31 PM, Heikki Linnakangas wrote: Dave Cramer wrote: Since PITR has to enable archiving does this not increase the amount of disk I/O required ? There

[PERFORM] postgresql running on a virtual cluster

Does anyone have any experience running pg on multiple IBM 3950's set up as a single machine ? Dave ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED]

[PERFORM] How much ram is too much

Is it possible that providing 128G of ram is too much ? Will other systems in the server bottleneck ? Dave ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Re: [PERFORM] How much ram is too much

It's an IBM x3850 using linux redhat 4.0 On 8-Jun-07, at 12:46 PM, Guy Rouillier wrote: Dave Cramer wrote: Is it possible that providing 128G of ram is too much ? Will other systems in the server bottleneck ? What CPU and OS are you considering? -- Guy Roui

Re: [OT] Re: [PERFORM] How much ram is too much

On 8-Jun-07, at 2:10 PM, Joshua D. Drake wrote: Zoltan Boszormenyi wrote: Dave Cramer írta: It's an IBM x3850 using linux redhat 4.0 Isn't that a bit old? I have a RedHat 4.2 somewhere that was bundled with Applixware 3. :-) He means redhat ES/AS 4 I assume.

Re: [PERFORM] How much ram is too much

Actually this one is an opteron, so it looks like it's all good. Dave On 8-Jun-07, at 3:41 PM, Guy Rouillier wrote: Dave Cramer wrote: It's an IBM x3850 using linux redhat 4.0 I had to look that up, web site says it is a 4-processor, dual-core (so 8 cores) Intel Xeon system. It

Re: [PERFORM] How much ram is too much

On 10-Jun-07, at 11:11 PM, Jim Nasby wrote: On Jun 8, 2007, at 11:31 AM, Dave Cramer wrote: Is it possible that providing 128G of ram is too much ? Will other systems in the server bottleneck ? Providing to what? PostgreSQL? The OS? My bet is that you'll run into issues wit

Re: [PERFORM] How much ram is too much

Hi Andrew On 11-Jun-07, at 11:34 AM, Andrew Sullivan wrote: On Mon, Jun 11, 2007 at 11:09:42AM -0400, Dave Cramer wrote: and set them to anything remotely close to 128GB. Well, we'd give 25% of it to postgres, and the rest to the OS. Are you quite sure that PostgreSQL's managem

Re: [PERFORM] How much ram is too much

Hi Andrew On 11-Jun-07, at 11:34 AM, Andrew Sullivan wrote: On Mon, Jun 11, 2007 at 11:09:42AM -0400, Dave Cramer wrote: and set them to anything remotely close to 128GB. Well, we'd give 25% of it to postgres, and the rest to the OS. Are you quite sure that PostgreSQL's managem

[PERFORM] best use of an EMC SAN

Assuming we have 24 73G drives is it better to make one big metalun and carve it up and let the SAN manage the where everything is, or is it better to specify which spindles are where. Currently we would require 3 separate disk arrays. one for the main database, second one for WAL logs, thir

Re: [PERFORM] best use of an EMC SAN

On 11-Jul-07, at 10:05 AM, Gregory Stark wrote: "Dave Cramer" <[EMAIL PROTECTED]> writes: Assuming we have 24 73G drives is it better to make one big metalun and carve it up and let the SAN manage the where everything is, or is it better to specify which spindles are

Re: [PERFORM] best use of an EMC SAN

On 11-Jul-07, at 2:35 PM, Greg Smith wrote: On Wed, 11 Jul 2007, Jim Nasby wrote: I suppose an entirely in-memory database might be able to swamp a 2 drive WAL as well. You can really generate a whole lot of WAL volume on an EMC SAN if you're doing UPDATEs fast enough on data that is mos

Re: [PERFORM] Dell Hardware Recommendations

On 13-Aug-07, at 9:50 AM, Vivek Khera wrote: On Aug 10, 2007, at 4:36 PM, Merlin Moncure wrote: I'm not so sure I agree. They are using LSI firmware now (and so is everyone else). The servers are well built (highly subjective, I admit) and configurable. I have had some bad experiences wit

[PERFORM] Attempting to disable count triggers on cleanup

I have a database that we want to keep track of counts of rows. We have triggers on the rows which increment, and decrement a count table. In order to speed up deleting many rows we have added the following if user != 'mocospace_cleanup' then

Re: [PERFORM] Attempting to disable count triggers on cleanup

hubert depesz lubaczewski wrote: On Tue, Sep 25, 2007 at 07:08:42AM -0400, Dave Cramer wrote: ERROR: deadlock detected DETAIL: Process 23063 waits for ExclusiveLock on tuple (20502,48) of relation 48999028 of database 14510214; blocked by process 23110. Process 23110 waits for ShareLock

Re: [PERFORM] JDBC question for PG 8.3.9

On Wed, Apr 14, 2010 at 7:10 PM, Craig Ringer wrote: > On 15/04/10 04:49, Dave Crooke wrote: >> >> Hi foilks >> >> I am using PG 8.3 from Java. I am considering a performance tweak which >> will involve holding about 150 java.sql.PreparedStatment objects open >> against a single PGSQL connection.

Re: [PERFORM] Migration study, step 1: bulk write performance optimization

Others are reporting better performance on 8.1.x with very large shared buffers. You may want to try tweaking that possibly as high as 20% of available memory Dave On 20-Mar-06, at 9:59 AM, Mikael Carneholm wrote: Ok, here's the deal: I am responisble for an exciting project of evaluating

Re: [PERFORM] PostgreSQL performance issues

On 30-Aug-06, at 7:35 AM, Willo van der Merwe wrote: Luke Lonergan wrote: Currently the load looks like this: Cpu0 : 96.8% us, 1.9% sy, 0.0% ni, 0.3% id, 0.0% wa, 0.0% hi, 1.0% si Cpu1 : 97.8% us, 1.6% sy, 0.0% ni, 0.3% id, 0.0% wa, 0.0% hi, 0.3% si Cpu2 : 96.8% us, 2.6% sy

Re: [PERFORM] performance problems.

On 30-Aug-06, at 10:10 AM, Vivek Khera wrote: On Aug 30, 2006, at 5:29 AM, Matthew Sullivan wrote: The hardware is a Compaq 6400r with 4G of EDO RAM, 4x500MHz Xeons and a Compaq RAID 3200 in RAID 5 configuration running across 3 spindles (34G total space). The OS is FreeBSD 5.4-RELEASE-

Re: [PERFORM] Postgress memory leak with JBoss3.2.6 and large DB

On 31-Aug-06, at 1:54 PM, Tom Lane wrote: "Indika Maligaspe" <[EMAIL PROTECTED]> writes: The problem is when we are querying a specific set of table (which all tables having over 100K of rows), the Postgres user process takes over or close 700MB of memory. This is just to return 3000 odd r

Re: [PERFORM] High concurrency OLTP database performance tuning

On 31-Aug-06, at 11:45 AM, Cosimo Streppone wrote: Good morning, I'd like to ask you some advice on pg tuning in a high concurrency OLTP-like environment. The application I'm talking about is running on Pg 8.0.1. Under average users load, iostat and vmstat show that iowait stays well under 1%.

Re: [PERFORM] performance problems.

On 31-Aug-06, at 2:15 PM, Vivek Khera wrote: On Aug 30, 2006, at 7:48 PM, Dave Cramer wrote: Actually unless you have a ram disk you should probably leave random_page_cost at 4, shared buffers should be 2x what you have here, maintenance work mem is pretty high effective cache should be

Re: [PERFORM] increasing shared buffers: how much should be removed from OS filesystem cache?

Guillaume 1G is really not a significant amount of memory these days, That said 6-10% of available memory should be given to an 8.0 or older version of postgresql Newer versions work better around 25% I'm not sure what you mean by mechanically removed from effective_cache effective cache i

Re: [PERFORM] increasing shared buffers: how much should be removed from OS filesystem cache?

On 1-Sep-06, at 3:49 PM, Merlin Moncure wrote: On 01 Sep 2006 19:00:52 +0200, Guillaume Cottenceau <[EMAIL PROTECTED]> wrote: Hi, I've been looking at the results from the pg_statio* tables, to view the impact of increasing the shared buffers to increase performance. I think 'shared buffer

Re: [PERFORM] database bloat,non removovable rows, slow query etc... [RESOLVED]

Matteo, On 2-Sep-06, at 4:37 AM, Matteo Sgalaberni wrote: On Fri, Sep 01, 2006 at 01:35:20PM -0400, Tom Lane wrote: Matteo Sgalaberni <[EMAIL PROTECTED]> writes: Ok. I stopped all clients. No connections to this database. When you say "this database", do you mean the whole postmaster clus

Re: [PERFORM] increasing shared buffers: how much should be removed from OS filesystem cache?

On 4-Sep-06, at 8:07 AM, Guillaume Cottenceau wrote: Dave Cramer writes: Guillaume 1G is really not a significant amount of memory these days, Yeah though we have 2G or 4G of RAM in our servers (and not only postgres running on it). That said 6-10% of available memory should be given

Re: [PERFORM] increasing shared buffers: how much should be removed

On 5-Sep-06, at 9:31 AM, Merlin Moncure wrote: On 9/1/06, Joshua D. Drake <[EMAIL PROTECTED]> wrote: >> >> I think 'shared buffers' is one of the most overrated settings from a >> performance standpoint. however you must ensure there is enough for >> things the server does besides caching

Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures

Hi, Arjen, On 8-Sep-06, at 1:51 AM, Arjen van der Meijden wrote: Hi, We've been running our "webapp database"-benchmark again on mysql and postgresql. This time using a Fujitsu-Siemens RX300 S3 machine equipped with a 2.66Ghz Woodcrest (5150) and a 3.73Ghz Dempsey (5080). And compared t

Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with postgresql and some SAS raid-figures

On 8-Sep-06, at 8:44 AM, Arjen van der Meijden wrote: Dave Cramer wrote: Hi, Arjen, The Woodcrest is quite a bit faster than the Opterons. Actually... With Hyperthreading *enabled* the older Dempsey- processor is also faster than the Opterons with PostgreSQL. But then again, it is the

Re: [PERFORM] Poor performance on seq scan

On 13-Sep-06, at 6:16 AM, Laszlo Nagy wrote: I have had extremely bad performance historically with onboard SATA chipsets on Linux. The one exception has been with the Intel based chipsets (not the CPU, the I/O chipset). This board has Intel chipset. I cannot remember the exact type but

Re: [PERFORM] sql-bench

All of the tuning parameters would affect all queries shared buffers, wal buffers, effective cache, to name a few --dc-- On 13-Sep-06, at 8:24 AM, yoav x wrote: Hi I am trying to run sql-bench against PostgreSQL 8.1.4 on Linux. Some of the insert tests seems to be ver slow For example: selec

Re: [PERFORM] sql-bench

AM, yoav x wrote: So why are these queries so slow in PG? --- Dave Cramer <[EMAIL PROTECTED]> wrote: All of the tuning parameters would affect all queries shared buffers, wal buffers, effective cache, to name a few --dc-- On 13-Sep-06, at 8:24 AM, yoav x wrote: Hi I am trying to run s

Re: [PERFORM] sql-bench

Have you tuned postgresql ? You still haven't told us what the machine is, or the tuning parameters. If you follow Merlin's links you will find his properly tuned postgres out performs mysql in every case. --dc-- On 14-Sep-06, at 2:55 AM, yoav x wrote: You can use the test with InnoDB by g

Re: [PERFORM] Vacuums on large busy databases

On 14-Sep-06, at 11:23 AM, Francisco Reyes wrote: My setup: Freebsd 6.1 Postgresql 8.1.4 Memory: 8GB SATA Disks Raid 1 10 spindles (2 as hot spares) 500GB disks (16MB buffer), 7200 rpm Raid 10 Raid 2 4 spindles 150GB 10K rpm disks Raid 10 shared_buffers = 1 shared buffers should be consi

Re: [PERFORM] Vacuums on large busy databases

Francisco On 14-Sep-06, at 1:36 PM, Francisco Reyes wrote: Dave Cramer writes: What is effective_cache set to ? Increasing this seems to have helped significantly a web app. Load times seem magnitudes faster. Increased it to effective_cache_size = 12288 # 96MB What is a reasonable

Re: [PERFORM] Vacuums on large busy databases

Francisco On 14-Sep-06, at 4:30 PM, Francisco Reyes wrote: Dave Cramer writes: What is a reasonable number? I estimate I have at least 1 to 2 GB free of memory. You are using 6G of memory for something else ? Right now adding up from ps the memory I have about 2GB. Have an occassional

Re: [PERFORM] Vacuums on large busy databases

On 14-Sep-06, at 7:50 PM, Francisco Reyes wrote: Dave Cramer writes: personally, I'd set this to about 6G. This doesn't actually consume memory it is just a setting to tell postgresql how much memory is being used for cache and kernel buffers Gotcha. Will increase further.

Re: [PERFORM] Opteron vs. Xeon "benchmark"

On 23-Sep-06, at 9:00 AM, Guido Neitzer wrote: I find the benchmark much more interesting in comparing PostgreSQL to MySQL than Intel to AMD. It might be as biased as other "benchmarks" but it shows clearly something that a lot of PostgreSQL user always thought: MySQL gives up on concurrency ..

Re: [PERFORM] Opteron vs. Xeon "benchmark"

On 23-Sep-06, at 9:49 AM, Guido Neitzer wrote: On 9/23/06, Dave Cramer <[EMAIL PROTECTED]> wrote: 1) The database fits entirely in memory, so this is really only testing CPU, not I/O which should be taken into account IMO I don't think this really is a reason that MySQL broke

Re: [PERFORM] New hardware thoughts

Ben, On 20-Oct-06, at 3:49 AM, Ben Suffolk wrote: Hello all, I am currently working out the best type of machine for a high volume pgsql database that I going to need for a project. I will be purchasing a new server specifically for the database, and it won't be running any other applica

Re: [PERFORM] Jdbc/postgres performance

On 17-Oct-06, at 3:05 PM, Behl, Rohit ((Infosys)) wrote: HiWe are facing performance problems in postgres while executing a query. When I execute this query on the server it takes 5-10 seconds. Also I get good performance while executing this query from my code in java with the hard codes values.

Re: [PERFORM] shared_buffers > 284263 on OS X

Brian, On 16-Nov-06, at 7:03 PM, Brian Wipf wrote: I'm trying to optimize a PostgreSQL 8.1.5 database running on an Apple G5 Xserve (dual G5 2.3 GHz w/ 8GB of RAM), running Mac OS X 10.4.8 Server. The queries on the database are mostly reads, and I know a larger shared memory allocation w

Re: [PERFORM] Toooo many context switches (maybe SLES8?)

uing the possibility that this has something to do with > the ServerWorks chipset on those motherboards. If anyone knows a high-end > hardware+linux kernel geek I can corner, I'd appreciate it. > > Maybe I should contact OSDL ... -- Dave Cramer 519 939

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

gt; restructured to reduce lock contention, but if he had come up with > anything he didn't mention exactly what. Neil? > > regards, tom lane > > ---(end of broadcast)--- > TIP 2: you can get off all list

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

, tom lane > > ---(end of broadcast)------- > TIP 8: explain analyze is your friend > > > > !DSPAM:40834781158911062514350! > > -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 8: explain analyze is your friend

Re: [PERFORM] Horribly slow hash join

regards, tom lane > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing lis

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

- > TIP 5: Have you checked our extensive FAQ? > >http://www.postgresql.org/docs/faqs/FAQ.html > > > > !DSPAM:40851da1199651145780980! > > -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)---

Re: [PERFORM] Toooo many context switches (maybe SLES8?)

lane > > > > > > > > > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > > > > !DSPAM:408535ce93801252113544! > > -- Dave Cramer 519 939 0336 ICQ # 14675561 ---(end of broadcast)--- TIP 8: explain analyze is your friend

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

tches ? Dave On Tue, 2004-04-20 at 12:59, Josh Berkus wrote: > Anjan, > > > Quad 2.0GHz XEON with highest load we have seen on the applications, DB > > performing great - > > Can you run Tom's test? It takes a particular pattern of data access to > reproduce the is

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

00 server > > > > > > > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > > > > !

  1   2   >