Re: [PERFORM] suboptimal query plan

2012-10-02 Thread Tom Lane
Nick Hofstede 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 regards, t

[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 con

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

2012-10-02 Thread Scott Marlowe
On Tue, Oct 2, 2012 at 9:14 AM, Bruce Momjian 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. This

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 is

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

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 an

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. >> To: pgsql-performance@postgre

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 th

Re: [PERFORM] hardware advice

2012-10-02 Thread Glyn Astill
> > From: M. D. >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 to ha

[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 w

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 l