Re: [PERFORM] Dell PERC H700/H800

Joshua D. Drake wrote: On Thu, 2010-02-11 at 12:39 +, Matthew Wakeling wrote: Just a heads up - apparently the more recent Dell RAID controllers will no longer recognise hard discs that weren't sold through Dell. http://www.channelregister.co.uk/2010/02/10/dell_perc_11th_gen_qualified_hdds

Re: [PERFORM] Best suiting OS

Devrim GÜNDÜZ wrote: On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote: Go for Debian: * It is a free community, very active. Well, we need to state that this is not a unique feature. * It is guaranteed to be upgradable. Depends. I had lots of issues with upgrade process in the pa

Re: [PERFORM] Best suiting OS

Stefan Kaltenbrunner wrote: Devrim GÜNDÜZ wrote: On Mon, 2009-10-05 at 12:07 +0200, Jean-Michel Pouré wrote: Go for Debian: * It is a free community, very active. Well, we need to state that this is not a unique feature. * It is guaranteed to be upgradable. Depends. I had lots of issues

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

Scott Carey wrote: On 7/30/09 11:24 AM, "Stefan Kaltenbrunner" wrote: Kevin Grittner wrote: Tom Lane wrote: "Kevin Grittner" writes: Since the dump to custom format ran longer than the full pg_dump piped directly to psql would have taken, the overall time to u

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

Kevin Grittner wrote: Tom Lane wrote: "Kevin Grittner" writes: Since the dump to custom format ran longer than the full pg_dump piped directly to psql would have taken, the overall time to use this technique is clearly longer for our databases on our hardware. Hmmm ... AFAIR there isn't a go

Re: [PERFORM] PostgreSQL 8.4 performance tuning questions

Tom Lane wrote: "Kevin Grittner" writes: Since the dump to custom format ran longer than the full pg_dump piped directly to psql would have taken, the overall time to use this technique is clearly longer for our databases on our hardware. Hmmm ... AFAIR there isn't a good reason for dump to c

Re: [PERFORM] hyperthreaded cpu still an issue in 8.4?

Greg Smith wrote: On Wed, 29 Jul 2009, Stefan Kaltenbrunner wrote: Well the real problem is that pgbench itself does not scale too well to lots of concurrent connections and/or to high transaction rates so it seriously skews the result. Sure, but that's what the multi-threaded pgbench

Re: [PERFORM] hyperthreaded cpu still an issue in 8.4?

Greg Smith wrote: On Tue, 28 Jul 2009, Scott Marlowe wrote: Just FYI, I ran the same basic test but with -c 10 since -c shouldn't really be greater than -s That's only true if you're running the TPC-B-like or other write tests, where access to the small branches table becomes a serious hotsp

Re: [PERFORM] 8.4 COPY performance regression on Solaris

Alan Li wrote: Hi, It seems that a COPY of 8M rows to a table to 8.4rc1 takes >30% longer than it does to 8.3.7 on Solaris. Here are the steps I've taken to reproduce this problem on two different solaris boxes (Solaris 10 11/06 s10x_u3wos_10 X86 and Solaris 10 8/07 s10x_u4wos_12b X86). I'

Re: [PERFORM] PostgreSQL with PostGIS on embedded hardware

Greg Stark wrote: On Mon, May 11, 2009 at 5:05 PM, Stefan Kaltenbrunner wrote: Good to know!!! I imagine that on a PS3 it would be _really_ fast... :-) well not really - while it is fairly easy to get postgresql running on a PS3 it is not a fast platform. While the main CPU there is a pretty

Re: [PERFORM] Any better plan for this query?..

Matthew Wakeling wrote: On Tue, 12 May 2009, Simon Riggs wrote: won't connect operations be all handled by a single thread - the parent postmaster? No, we spawn then authenticate. But you still have a single thread doing the accept() and spawn. At some point (maybe not now, but in the futur

Re: [PERFORM] Any better plan for this query?..

Dimitri wrote: Hi Stefan, sorry, I did not have a time to bring all details into the toolkit - but at least I published it instead to tell a "nice story" about :-) fair point and appreciated. But it seems important that benchmarking results can be verified by others as well... The client

Re: [PERFORM] Any better plan for this query?..

Dimitri wrote: Folks, before you start to think "what a dumb guy doing a dumb thing" :-)) I'll explain you few details: it's for more than 10 years I'm using a db_STRESS kit (http://dimitrik.free.fr/db_STRESS.html) to check databases performance and scalability. Until now I was very happy with r

Re: [PERFORM] PostgreSQL with PostGIS on embedded hardware

Paolo Rizzi wrote: Are you saying that PostgreSQL+PostGIS can actually run on a smartphone??? Intriguing... Did anyone ever actually tried that??? If it's a supported CPU type and you've got a suitable build toolchain, sure. Seven or eight years ago we were getting a good laugh out of the fac

Re: [PERFORM] How to "unique-ify" HUGE table?

Scott Marlowe wrote: On Tue, Dec 23, 2008 at 11:14 AM, George Pavlov wrote: You don't say what PG version you are on, but just for kicks you may try using GROUP BY instead of DISTINCT. Yes, the two should perform the same, but with 8.1 (or maybe 8.0) I had seen situations where GROUP BY was fas

Re: [PERFORM] Explain Analyze - Total runtime very differentes

[EMAIL PROTECTED] wrote: Hello friends ... I'm evaluating the performance of algorithms for optimization of queries. I am comparing results between the algorithm of Dynamic Programming and an implementation of Kruskal's algorithm. When submitting a query that makes reference to only 2 tables of

Re: [PERFORM] pg_dump error - out of memory, Failed on request of size 536870912

Marcin Citowicki wrote: Hello, I forgot to add - all those 'out of memory' errors happen when backup db is trying to create index. Every 'CREATE INDEX' operation is followed by 'out of memory' error. are you sure that your OS (or ulimit) is able to support a maintenance_work_setting that la

Re: [PERFORM] URI to kind of a benchmark

Harald Armin Massa wrote: reading postgres benchmarks for beginners advises to stop reading on the words "default (ie. unchanged postgresql.conf); but the real test is given right after: http://www.kaltenbrunner.cc/blog/index.php?/archives/21-guid.html That confirmes my first impression (on d

Re: [PERFORM] DRBD and Postgres: how to improve the perfomance?

Joshua D. Drake wrote: > Stefan Kaltenbrunner wrote: >> Joshua D. Drake wrote: >>> Gregory Stark wrote: >>>> "Simon Riggs" <[EMAIL PROTECTED]> writes: >>>>> You're right, but the distinction is a small one. What are the chances &g

Re: [PERFORM] DRBD and Postgres: how to improve the perfomance?

Joshua D. Drake wrote: > Gregory Stark wrote: >> "Simon Riggs" <[EMAIL PROTECTED]> writes: > >>> You're right, but the distinction is a small one. What are the chances >>> of losing two independent servers within a few milliseconds of each >>> other? >> If they're on the same power bus? > > That

Re: [PERFORM] [HACKERS] Proposal: Pluggable Optimizer Interface

Julius Stroffek wrote: > Hi All, > > Tomas Kovarik and I have presented at PGCon 2007 in Ottawa > the ideas about other possible optimizer algorithms to be used > in PostgreSQL. > > We are quite new to PostgreSQL project so it took us some > time to go through the sources end explore the possibil

Re: [PERFORM] Postgres configuration for 64 CPUs, 128 GB RAM...

Marc Mamin wrote: Postgres configuration for 64 CPUs, 128 GB RAM... there are probably not that much installation out there that large - comments below Hello, We have the oppotunity to benchmark our application on a large server. I have to prepare the Postgres configuration and I'd appr

Re: [PERFORM] PostgreSQL publishes first real benchmark

Jignesh K. Shah wrote: > Can you list others that seemed out of place? well to me the ones that look most questionable are: work_mem=100MB - so this benchmark is really low concurrency(which does not fit with max_connections=1000) and with trivial queries ? enable_seqscan = off - why ? effectiv

Re: [PERFORM] PostgreSQL Configuration Tool for Dummies

Campbell, Lance wrote: > Now I am at the difficult part, what parameters to calculate and how to > calculate them. Everything below has to do with PostgreSQL version 8.2: > > > > The parameters I would think we should calculate are: > > max_connections > > shared_buffers > > work_mem > > m

Re: [PERFORM] upgraded to pgsql 8.2.4, getting worse performance then 7.4.x

Michael Fuhr wrote: > On Sat, Jun 02, 2007 at 09:13:32AM -0400, Douglas J Hunley wrote: >> Our 'esteemed' Engr group recently informed a customer that in their >> testing, >> upgrading to 8.2.x improved the performance of our J2EE >> application "approximately 20%", so of course, the customer th

Re: [PERFORM] Domains versus Check Constraints

Jim C. Nasby wrote: > On Tue, May 22, 2007 at 12:56:21PM -0400, Chander Ganesan wrote: >> Are there any performance improvements that come from using a domain >> over a check constraint (aside from the ease of management component)? > > No. Plus support for domain constraints isn't universal (plp

Re: [PERFORM] more on high load on postgres 7.4.16

Geoffrey wrote: > We are trying to attack this problem from multiple avenues, thus I'm > starting a separate thread. This is with regard to the problem posted > via thread: > > http://archives.postgresql.org/pgsql-performance/2007-04/msg00120.php > > One thing we are seeing with this move to the

Re: [PERFORM] SCSI vs SATA

Joshua D. Drake wrote: SATAII brute forces itself through some of its performance, for example 16MB write cache on each drive. sure but for any serious usage one either wants to disable that cache(and rely on tagged command queuing or how that is called in SATAII Why? Assuming we have a B

Re: [PERFORM] SCSI vs SATA

Joshua D. Drake wrote: Good point. On another note, I am wondering why nobody's brought up the command-queuing perf benefits (yet). Is this because sata vs scsi are at SATAII has similar features. par here? I'm finding conflicting information on this -- some calling sata's ncq mostly cr

Re: OT: Munin (was Re: [PERFORM] Determining server load from client)

CAJ CAJ wrote: > > > On 3/21/07, *Erik Jones* <[EMAIL PROTECTED] > wrote: > > > On Mar 21, 2007, at 4:13 PM, Tobias Brox wrote: > >> [Erik Jones - Wed at 09:31:48AM -0500] >>> I use cacti (http://cacti.net) which does the same thing that >>> munin >>

Re: [PERFORM] [EMAIL PROTECTED]: Progress on scaling of FreeBSD on 8 CPU systems]

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> Arjen van der Meijden wrote: >>> Stefan Kaltenbrunner wrote: >>>> ouch - do I read that right that even after tom's fixes for the >>>> "regressions" in 8.2.0 we ar

Re: [PERFORM] [EMAIL PROTECTED]: Progress on scaling of FreeBSD on 8 CPU systems]

Arjen van der Meijden wrote: > Stefan Kaltenbrunner wrote: >> ouch - do I read that right that even after tom's fixes for the >> "regressions" in 8.2.0 we are still 30% slower then the -HEAD checkout >> from the middle of the 8.2 development cycle ? >

Re: [PERFORM] [EMAIL PROTECTED]: Progress on scaling of FreeBSD on 8 CPU systems]

Arjen van der Meijden wrote: And here is that latest benchmark we did, using a 8 dual core opteron Sun Fire x4600. Unfortunately PostgreSQL seems to have some difficulties scaling over 8 cores, but not as bad as MySQL. http://tweakers.net/reviews/674 ouch - do I read that right that even aft

Re: [PERFORM] Opinions on Raid

Joe Uhl wrote: We have been running Postgres on a 2U server with 2 disks configured in raid 1 for the os and logs and 4 disks configured in raid 10 for the data. I have since been told raid 5 would have been a better option given our usage of Dell equipment and the way they handle raid 10. I ha

Re: [PERFORM] Monitoring Transaction Log size

Joshua D. Drake wrote: > Ziegelwanger, Silvio wrote: >> Hi, >> >> >> >> how can I monitor the size of the transaction log files using SQL Statements? > > You can't. You would have to write a custom function to heck the size of > the xlog directory. wel in recent versions of pg it should be pret

Re: [PERFORM] Performance of ORDER BY

Steinar H. Gunderson wrote: > On Tue, Dec 05, 2006 at 01:02:06PM -0500, Tom Lane wrote: >> In 8.0 that might be counterproductively high --- we have seen cases >> where more sort_mem = slower with the older sorting code. I concur >> with Luke's advice that you should update to 8.2 (not 8.1) to get

Re: [PERFORM] Best COPY Performance

Luke Lonergan wrote: Stefan, On 10/30/06 8:57 AM, "Stefan Kaltenbrunner" <[EMAIL PROTECTED]> wrote: We've found that there is an ultimate bottleneck at about 12-14MB/s despite having sequential write to disk speeds of 100s of MB/s. I forget what the latest bottleneck wa

Re: [PERFORM] Best COPY Performance

Luke Lonergan wrote: Greg, On 10/30/06 7:09 AM, "Spiegelberg, Greg" <[EMAIL PROTECTED]> wrote: I broke that file into 2 files each of 550K rows and performed 2 simultaneous COPY's after dropping the table, recreating, issuing a sync on the system to be sure, &c and nearly every time both COPY'

Re: [PERFORM] Xeon Woodcrest/Dempsey vs Opteron Socket F/940 with

Arjen van der Meijden wrote: > On 8-9-2006 15:01 Dave Cramer wrote: >> >>> But then again, systems with the Woodcrest 5150 (the subtop one) and >>> Opteron 280 (also the subtop one) are about equal in price, so its >>> not a bad comparison in a bang-for-bucks point of view. The Dempsey >>> was adde

Re: [PERFORM] Kill a session

Craig A. James wrote: > Magnus Hagander wrote: >>> This raises the question: Why doesn't Postgres have a "kill session" >>> command that works? Oracle has it, and it's invaluable; there is no >>> substitute. Various writers to these PG lists have raised the >>> question repeatedly. Is it just a

Re: [PERFORM] VACUUM vs. REINDEX

Steinar H. Gunderson wrote: > On Fri, Jul 07, 2006 at 09:28:52PM -0400, Chris Hoover wrote: >> You need to increase your fsm settings. The database is telling you it is >> trying to store 177K+ pages, but you have only provided it with 20K. Since >> these pages are cheap, I would set your fsm up

Re: [PERFORM] SAN performance mystery

Tim Allen wrote: > We have a customer who are having performance problems. They have a > large (36G+) postgres 8.1.3 database installed on an 8-way opteron with > 8G RAM, attached to an EMC SAN via fibre-channel (I don't have details > of the EMC SAN model, or the type of fibre-channel card at the

Re: [PERFORM] good pc but bad performance,why?

huang yaqin wrote: hello, I have some question when I use postgresql 7.4.1 on redhat adv server 2.1 . I use IBM335 as server, it has 4 cpus, 1G RAM. but I got very bad performance. This is most likely a dual processor Xeon machine with HT, because the x335 is limited to two physical cpus.