Re: [PERFORM] Spurious failure to obtain row lock possible in PG 9.1?

2012-10-02 Thread henk de wit
Hi there, henk de wit wrote: I'm using Postgres 9.1 on Debian Lenny and via a Java server (JBoss AS I'm pretty sure there's really no other process that has the lock, as I'm the only one on a test DB. If I execute the query immediately again, it does succeed in obtaining the lock. I can

[PERFORM] deadlock_timeout affect on performance

2012-10-02 Thread pg noob
Hi all, I have a question about the deadlock_timeout in regards to performance. Right now we have this timeout set at its default of 1s. My understanding of it is that this means that every 1 second the server will check for deadlocks. What I am wondering is how much of a performance improvement

Re: [PERFORM] hardware advice

2012-10-02 Thread Glyn Astill
From: M. D. li...@turnkey.bz To: pgsql-performance@postgresql.org Sent: Friday, 28 September 2012, 18:33 Subject: Re: [PERFORM] hardware advice On 09/28/2012 09:57 AM, David Boreham wrote: On 9/28/2012 9:46 AM, Craig James wrote: Your best warranty would be

Re: [PERFORM] deadlock_timeout affect on performance

2012-10-02 Thread Heikki Linnakangas
On 01.10.2012 19:49, pg noob wrote: Hi all, I have a question about the deadlock_timeout in regards to performance. Right now we have this timeout set at its default of 1s. My understanding of it is that this means that every 1 second the server will check for deadlocks. Not quite. It means

Re: [PERFORM] hardware advice - opinions about HP?

2012-10-02 Thread Franklin, Dan (FEN)
From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Glyn Astill Sent: Tuesday, October 02, 2012 4:21 AM To: M. D.; pgsql-performance@postgresql.org Subject: Re: [PERFORM] hardware advice From: M. D. li...@turnkey.bz To:

Re: [PERFORM] Inserts in 'big' table slowing down the database

2012-10-02 Thread Shaun Thomas
On 10/01/2012 07:15 PM, Stefan Keller wrote: Any ideas? Partitioning? Yes. Make sure you have a good column to partition on. Tables this large are just bad performers in general, and heaven forbid you ever have to perform maintenance on them. We had a table that size, and simply creating

Re: [PERFORM] hardware advice - opinions about HP?

2012-10-02 Thread Bruce Momjian
On Tue, Oct 2, 2012 at 10:51:46AM -0400, Franklin, Dan (FEN) wrote: Look around and find another vendor, even if your company has to pay more for you to have that blame avoidance. We're currently using Dell and have had enough problems to think about switching. What about HP? If you

Re: [PERFORM] hardware advice

2012-10-02 Thread David Boreham
On 10/2/2012 2:20 AM, Glyn Astill wrote: newer R910s recently all of a sudden went dead to the world; no prior symptoms showing in our hardware and software monitoring, no errors in the os logs, nothing in the dell drac logs. After a hard reset it's back up as if nothing happened, and it's an

Re: [PERFORM] hardware advice - opinions about HP?

2012-10-02 Thread Scott Marlowe
On Tue, Oct 2, 2012 at 9:14 AM, Bruce Momjian br...@momjian.us wrote: On Tue, Oct 2, 2012 at 10:51:46AM -0400, Franklin, Dan (FEN) wrote: We're currently using Dell and have had enough problems to think about switching. What about HP? If you need a big vendor, I think HP is a good choice.

[PERFORM] suboptimal query plan

2012-10-02 Thread Nick Hofstede
I'm struggling with a query that seems to use a suboptimal query plan. Schema: units reference a subjob reference a job. In other words: a job contains multiple subjobs. A subjob contains multiple units. (full schema below) We're trying to select all subjobs that need to be reviewed and that

Re: [PERFORM] suboptimal query plan

2012-10-02 Thread Tom Lane
Nick Hofstede nick.hofst...@inventivegroup.com writes: I'm struggling with a query that seems to use a suboptimal query plan. Try it in 9.2 - this is the same type of join ordering restriction complained of last week here: http://archives.postgresql.org/pgsql-performance/2012-09/msg00201.php