[PERFORM] Samsung 32GB SATA SSD tested

2008-07-22 Thread Jeffrey W. Baker
For background, please read the thread Fusion-io ioDrive, archived at http://archives.postgresql.org/pgsql-performance/2008-07/msg00010.php To recap, I tested an ioDrive versus a 6-disk RAID with pgbench on an ordinary PC. I now also have a 32GB Samsung SATA SSD, and I have tested it in the

Re: [PERFORM] Storing Digital Video

2006-02-04 Thread Jeffrey W. Baker
On Tue, 2006-01-31 at 16:32 -0800, Rodrigo Madera wrote: I am concerned with performance issues involving the storage of DV on a database. I though of some options, which would be the most advised for speed? 1) Pack N frames inside a container and store the container to the db. 2) Store

Re: [PERFORM] Huge Data sets, simple queries

2006-02-01 Thread Jeffrey W. Baker
On Tue, 2006-01-31 at 21:53 -0800, Luke Lonergan wrote: Jeffrey, On 1/31/06 8:09 PM, Jeffrey W. Baker [EMAIL PROTECTED] wrote: ... Prove it. I think I've proved my point. Software RAID1 read balancing provides 0%, 300%, 100%, and 100% speedup on 1, 2, 4, and 8 threads, respectively

Re: [PERFORM] Index Usage using IN

2006-02-01 Thread Jeffrey W. Baker
On Thu, 2006-02-02 at 09:12 +1300, Ralph Mason wrote: Hi, I have 2 tables both have an index on ID (both ID columns are an oid). I want to find only only rows in one and not the other. Select ID from TableA where ID not IN ( Select ID from Table B) Have you considered this: SELECT ID

Re: [PERFORM] Index Usage using IN

2006-02-01 Thread Jeffrey W. Baker
On Wed, 2006-02-01 at 12:22 -0800, Jeffrey W. Baker wrote: On Thu, 2006-02-02 at 09:12 +1300, Ralph Mason wrote: Hi, I have 2 tables both have an index on ID (both ID columns are an oid). I want to find only only rows in one and not the other. Select ID from TableA where ID

Re: [PERFORM] Huge Data sets, simple queries

2006-01-29 Thread Jeffrey W. Baker
On Sun, 2006-01-29 at 13:44 -0500, Luke Lonergan wrote: Depesz, [mailto:[EMAIL PROTECTED] On Behalf Of hubert depesz lubaczewski Sent: Sunday, January 29, 2006 3:25 AM hmm .. do i understand correctly that you're suggesting that using raid 10 and/or hardware raid adapter might

Re: [PERFORM] Huge Data sets, simple queries

2006-01-28 Thread Jeffrey W. Baker
On Sat, 2006-01-28 at 10:55 -0500, Tom Lane wrote: Assuming that month means what it sounds like, the above would result in running twelve parallel sort/uniq operations, one for each month grouping, to eliminate duplicates before counting. You've got sortmem set high enough to blow out RAM

Re: [PERFORM] Huge Data sets, simple queries

2006-01-27 Thread Jeffrey W. Baker
On Fri, 2006-01-27 at 20:23 -0500, Mike Biamonte wrote: Does anyone have any experience with extremely large data sets? I'm mean hundreds of millions of rows. Sure, I think more than a few of us do. Just today I built a summary table from a 25GB primary table with ~430 million rows. This

[PERFORM] Process executing COPY opens and reads every table on the system

2005-12-29 Thread Jeffrey W. Baker
I have an instance of PG 7.4 where I would really like to execute some schema changes, but every schema change is blocked waiting for a process doing a COPY. That query is: COPY drill.trades (manager, sec_id, ticker, bridge_tkr, date, type, short, quantity, price, prin, net_money, factor) TO

[PERFORM] Invulnerable VACUUM process thrashing everything

2005-12-29 Thread Jeffrey W. Baker
A few WEEKS ago, the autovacuum on my instance of pg 7.4 unilaterally decided to VACUUM a table which has not been updated in over a year and is more than one terabyte on the disk. Because of the very high transaction load on this database, this VACUUM has been ruining performance for almost a

Re: [PERFORM] Invulnerable VACUUM process thrashing everything

2005-12-29 Thread Jeffrey W. Baker
signal to get through. Hope this helps, Ron At 05:09 PM 12/29/2005, Jeffrey W. Baker wrote: A few WEEKS ago, the autovacuum on my instance of pg 7.4 unilaterally decided to VACUUM a table which has not been updated in over a year and is more than one terabyte on the disk. Because

Re: [PERFORM] opinion on disk speed

2005-12-08 Thread Jeffrey W. Baker
On Thu, 2005-12-08 at 11:52 -0500, Vivek Khera wrote: I have a choice to make on a RAID enclosure: 14x 36GB 15kRPM ultra 320 SCSI drives OR 12x 72GB 10kRPM ultra 320 SCSI drives both would be configured into RAID 10 over two SCSI channels using a megaraid 320-2x card. My goal is

Re: [HACKERS] [PERFORM] A Better External Sort?

2005-10-05 Thread Jeffrey W. Baker
On Wed, 2005-10-05 at 12:14 -0400, Ron Peacetree wrote: I've now gotten verification from multiple working DBA's that DB2, Oracle, and SQL Server can achieve ~250MBps ASTR (with as much as ~500MBps ASTR in setups akin to Oracle RAC) when attached to a decent (not outrageous, but decent) HD

Re: [PERFORM] Ultra-cheap NVRAM device

2005-10-03 Thread Jeffrey W. Baker
On Mon, 2005-10-03 at 11:15 -0600, Dan Harris wrote: On Oct 3, 2005, at 5:02 AM, Steinar H. Gunderson wrote: I thought this might be interesting, not the least due to the extremely low price ($150 + the price of regular DIMMs): This has been posted before, and the main reason

Re: [HACKERS] [PERFORM] A Better External Sort?

2005-09-29 Thread Jeffrey W. Baker
On Thu, 2005-09-29 at 10:06 -0700, Luke Lonergan wrote: Josh, On 9/29/05 9:54 AM, Josh Berkus josh@agliodbs.com wrote: Following an index creation, we see that 95% of the time required is the external sort, which averages 2mb/s. This is with seperate drives for the WAL, the pg_tmp,

Re: [HACKERS] [PERFORM] A Better External Sort?

2005-09-27 Thread Jeffrey W. Baker
On Tue, 2005-09-27 at 13:15 -0400, Ron Peacetree wrote: That Btree can be used to generate a physical reordering of the data in one pass, but that's the weakest use for it. The more powerful uses involve allowing the Btree to persist and using it for more efficient re-searches or combining

Re: [PERFORM] Battery Backed Cache for RAID

2005-09-14 Thread Jeffrey W. Baker
On Wed, 2005-09-14 at 11:25 -0700, Peter Darley wrote: I'm getting a new server for our database, and I have a quick question about RAID controllers with a battery backed cache. I understand that the cache will allow the cache to be written out if the power fails to the box, which

Re: [PERFORM] Observation about db response time

2005-09-05 Thread Jeffrey W. Baker
On Tue, 2005-08-30 at 08:13 -0500, Frank Wiles wrote: On Tue, 30 Aug 2005 18:35:30 +0530 Akshay Mathur [EMAIL PROTECTED] wrote: Hello Friends, We were having a database in pgsql7.4.2 The database was responding very slowly even after full vacuum analyze (select count(*) from

Re: [PERFORM] Limit + group + join

2005-08-25 Thread Jeffrey W. Baker
On Thu, 2005-08-25 at 18:56 -0700, Jeffrey W. Baker wrote: On Fri, 2005-08-26 at 02:27 +0200, Tobias Brox wrote: Consider this setup - which is a gross simplification of parts of our production system ;-) create table c (id integer primary key); create table b (id integer primary

Re: [PERFORM] Read/Write block sizes

2005-08-24 Thread Jeffrey W. Baker
On Wed, 2005-08-24 at 01:56 -0400, Tom Lane wrote: Jeffrey W. Baker [EMAIL PROTECTED] writes: On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote: Dont forget that already in postgres, you have a process per connection, and all the processes take care of their own I/O. That's

Re: [PERFORM] Read/Write block sizes (Was: Caching by Postgres)

2005-08-23 Thread Jeffrey W. Baker
On Tue, 2005-08-23 at 19:12 -0400, Michael Stone wrote: On Tue, Aug 23, 2005 at 05:29:01PM -0400, Jignesh Shah wrote: Actually some of that readaheads,etc the OS does already if it does some sort of throttling/clubbing of reads/writes. Note that I specified the fully cached case--even with

Re: [PERFORM] Read/Write block sizes

2005-08-23 Thread Jeffrey W. Baker
On Tue, 2005-08-23 at 19:31 -0700, Josh Berkus wrote: Steve, I would assume that dbt2 with STP helps minimize the amount of hours someone has to invest to determine performance gains with configurable options? Actually, these I/O operation issues show up mainly with DW workloads, so

Re: [PERFORM] Read/Write block sizes

2005-08-23 Thread Jeffrey W. Baker
On Wed, 2005-08-24 at 17:20 +1200, Guy Thornley wrote: As for the async IO, sure you might think 'oh async IO would be so cool!!' and I did, once, too. But then I sat down and _thought_ about it, and decided well, no, actually, theres _very_ few areas it could actually help, and in most cases

Re: [PERFORM] Query plan looks OK, but slow I/O - settings advice?

2005-08-19 Thread Jeffrey W. Baker
On Tue, 2005-08-16 at 10:46 -0700, Roger Hand wrote: The disks are ext3 with journalling type of ordered, but this was later changed to writeback with no apparent change in speed. They're on a Dell poweredge 6650 with LSI raid card, setup as follows: 4 disks raid 10 for indexes (145GB) -

Re: [PERFORM] Need for speed

2005-08-17 Thread Jeffrey W. Baker
On Wed, 2005-08-17 at 11:15 +0200, Ulrich Wisser wrote: Hello, thanks for all your suggestions. I can see that the Linux system is 90% waiting for disc io. At that time all my queries are *very* slow. My scsi raid controller and disc are already the fastest available. What RAID

Re: [PERFORM] Need for speed

2005-08-16 Thread Jeffrey W. Baker
On Tue, 2005-08-16 at 17:39 +0200, Ulrich Wisser wrote: Hello, one of our services is click counting for on line advertising. We do this by importing Apache log files every five minutes. This results in a lot of insert and delete statements. At the same time our customers shall be able

Re: [SPAM?] Re: [PERFORM] PG8 Tuning

2005-08-11 Thread Jeffrey W. Baker
On Fri, 2005-08-12 at 08:47 +, Steve Poe wrote: Paul, Before I say anything else, one online document which may be of assistance to you is: http://www.powerpostgresql.com/PerfList/ Some thoughts I have: 3) You're shared RAM setting seems overkill to me. Part of the challenge is

Re: [PERFORM] Performance problems on 4/8way Opteron (dualcore) HP

2005-07-29 Thread Jeffrey W. Baker
On Fri, 2005-07-29 at 10:46 -0700, Josh Berkus wrote: Dirk, does anybody have expierence with this machine (4x 875 dual core Opteron CPUs)? I'm using dual 275s without problems. Nope. I suspect that you may be the first person to report in on dual-cores. There may be special compile

Re: [PERFORM] Cheap RAM disk?

2005-07-26 Thread Jeffrey W. Baker
On Tue, 2005-07-26 at 11:34 -0500, John A Meinel wrote: I saw a review of a relatively inexpensive RAM disk over at anandtech.com, the Gigabyte i-RAM http://www.anandtech.com/storage/showdoc.aspx?i=2480 Basically, it is a PCI card, which takes standard DDR RAM, and has a SATA port on it,

Re: [PERFORM] Huge performance problem between 7.4.1 and 8.0.3 -

2005-07-17 Thread Jeffrey W. Baker
On Sun, 2005-07-17 at 21:34 -0600, Robert Creager wrote: Sigh... I recently upgraded from 7.4.1 to 8.0.3. The application did not change. I'm now running both database concurrently (on different ports, same machine) just so I could verify the problem really exists. The application is a

[PERFORM] more filesystem benchmarks

2005-07-16 Thread Jeffrey W. Baker
In our last installment, we saw that JFS provides higher pgbench performance than either XFS or ext3. Using a direct-I/O patch stolen from 8.1, JFS achieved 105 tps with 100 clients. To refresh, the machine in question has 5 7200RPM SATA disks, an Areca RAID controller with 128MB cache, and 1GB

Re: [PERFORM] Really bad diskio

2005-07-15 Thread Jeffrey W. Baker
On Fri, 2005-07-15 at 15:04 -0600, Ron Wills wrote: At Fri, 15 Jul 2005 13:45:07 -0700, Joshua D. Drake wrote: Ron Wills wrote: Hello all I'm running a postgres 7.4.5, on a dual 2.4Ghz Athlon, 1Gig RAM and an 3Ware SATA raid. 2 drives? 4 drives? 8 drives? 3

Re: [PERFORM] Really bad diskio

2005-07-15 Thread Jeffrey W. Baker
On Fri, 2005-07-15 at 15:29 -0600, Ron Wills wrote: Here's a bit of a dump of the system that should be useful. Processors x2: vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(tm) MP 2400+ stepping: 1 cpu MHz : 2000.474

[PERFORM] JFS fastest filesystem for PostgreSQL?

2005-07-14 Thread Jeffrey W. Baker
[reposted due to delivery error -jwb] I just took delivery of a new system, and used the opportunity to benchmark postgresql 8.0 performance on various filesystems. The system in question runs Linux 2.6.12, has one CPU and 1GB of system memory, and 5 7200RPM SATA disks attached to an Areca

Re: [PERFORM] JFS fastest filesystem for PostgreSQL?

2005-07-14 Thread Jeffrey W. Baker
On Thu, 2005-07-14 at 10:03 +0200, Dawid Kuroczko wrote: On 7/14/05, Jeffrey W. Baker [EMAIL PROTECTED] wrote: [reposted due to delivery error -jwb] I just took delivery of a new system, and used the opportunity to benchmark postgresql 8.0 performance on various filesystems. The system

[PERFORM] JFS fastest filesystem for PostgreSQL?

2005-07-14 Thread Jeffrey W. Baker
I just took delivery of a new system, and used the opportunity to benchmark postgresql 8.0 performance on various filesystems. The system in question runs Linux 2.6.12, has one CPU and 1GB of system memory, and 5 7200RPM SATA disks attached to an Areca hardware RAID controller having 128MB of