[PERFORM] About pg_stat_activity

2011-02-02 Thread Cesar Arrieta
Hi, im César, im developing an app that saves information included in pg_stat_activity view in order to monitor querys. The objective of this app is to gather information about querys that take to long to finish and overload the server. I was wandering if I could see somehwere the implementation

monitoring querys Re: [PERFORM] About pg_stat_activity

2011-02-02 Thread Jens Wilke
On Wednesday 02 February 2011 16:21:47 Cesar Arrieta wrote: Hi, If you could help looking about this, or if you know about an app that already do this, please let me know. have a look for http://pgfouine.projects.postgresql.org/ and http://pgfoundry.org/projects/pgstatspack/ HTH, Jens --

Re: [PERFORM] Are we in the ballpark?

2011-02-02 Thread Wayne Conrad
Greg, It's so nice to get a reply from the author of *the book*. Thank you for taking the time to help us out. On 02/01/11 18:30, Greg Smith wrote: Do you not want any excitement in your life? I've had database excitement enough to last a lifetime. That's why I'm mending my ways. Your

Re: [PERFORM] About pg_stat_activity

2011-02-02 Thread Maciek Sakrejda
I was wandering if I could see somehwere the implementation of pg_stat_activity view From psql \d+ pg_stat_activity --- Maciek Sakrejda | System Architect | Truviso 1065 E. Hillsdale Blvd., Suite 215 Foster City, CA 94404 www.truviso.com -- Sent via pgsql-performance mailing list

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Robert Haas
On Tue, Feb 1, 2011 at 6:44 PM, Mladen Gogala mladen.gog...@vmsinfo.com wrote: On 2/1/2011 6:03 PM, Andrew Dunstan wrote: Whether or not it's bad application design, it's ubiquitous, and we should make it work as best we can, IMNSHO. This often generates complaints about Postgres, and if we

Re: [PERFORM] About pg_stat_activity

2011-02-02 Thread Greg Smith
Cesar Arrieta wrote: im developing an app that saves information included in pg_stat_activity view in order to monitor querys. The objective of this app is to gather information about querys that take to long to finish and overload the server. I hope you're already setting

Re: [PERFORM] Configuration for a new server.

2011-02-02 Thread Benjamin Krajmalnik
See how buffers_backend is much larger than buffers_clean, even though maxwritten_clean is low?  That means the background writer isn't running often enough to keep up with cleaning things, even though it does a lot of work when it does kick in.  In your situation I'd normally do a first pass

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
Robert Haas wrote: On Tue, Feb 1, 2011 It would be pretty hard to make autoanalyze work on such tables without removing some of the performance benefits of having such tables in the first place - namely, the local buffer manager. But you could ANALYZE them by hand. Not necessarily

[PERFORM] Server Configuration

2011-02-02 Thread Cesar Arrieta
Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3. With Hardware: * 8GB RAM * 8 processors Intel Xeon E5520 @2.27GHz * 250GB SATA DISK Actually, it serves at most 250 connections. The problem happends when it serves many many connections at a time, tables and queries began to get

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Robert Haas
On Wed, Feb 2, 2011 at 1:11 PM, Mladen Gogala mladen.gog...@vmsinfo.com wrote: Not necessarily autoanalyze, some default rules for the situations when stats is not there should be put in place, like the following: 1) If there is a usable index on the temp table - use it. 2) It there isn't a

Re: [PERFORM] Configuration for a new server.

2011-02-02 Thread Greg Smith
Benjamin Krajmalnik wrote: So, if I understand correctly, I should strive for a relative increase in buffers_clean to buffers_backend Right. Buffers written by a backend are the least efficient way to get data out of the buffer cache, because the client running into that is stuck

Re: [PERFORM] Server Configuration

2011-02-02 Thread Kenneth Marshall
On Wed, Feb 02, 2011 at 03:15:22PM -0300, Cesar Arrieta wrote: Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3. With Hardware: * 8GB RAM * 8 processors Intel Xeon E5520 @2.27GHz * 250GB SATA DISK Actually, it serves at most 250 connections. The problem happends when it

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Robert Haas
On Wed, Feb 2, 2011 at 1:19 PM, Jon Nelson jnelson+pg...@jamponi.net wrote: However, sometimes using an index results in a HORRIBLE HORRIBLE plan. I recently encountered the issue myself, and plopping an ANALYZE $tablename in there, since I was using a temporary table anyway, make all the

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Greg Smith
Mladen Gogala wrote: People are complaining about the optimizer not using the indexes all over the place, there should be a way to make the optimizer explicitly prefer the indexes, like was the case with Oracle's venerable RBO (rules based optimizer). RBO didn't use statistics, it had a rank of

Re: [PERFORM] Exhaustive list of what takes what locks

2011-02-02 Thread Greg Smith
Nikolas Everett wrote: Is there an exhaustive list of what takes what locks and how long they last? I'm asking because we just had some trouble doing a hot db change to an 8.3.6 system. I know it is an old version but it is what I have to work with. There haven't been any major changes in

Re: [PERFORM] Server Configuration

2011-02-02 Thread Richard Carnes
I would personally highly recommend using pgBouncer! I have been using this in production migrating from MySQL and have had phenomenal success with it combined with lighttpd and php as an internal information system. I am getting on average 300 requests per second very low load average as it is

[Fwd: Re: [HACKERS] [PERFORM] Slow count(*) again...]

2011-02-02 Thread Mladen Gogala
I mistakenly replied to sender only. Jon Nelson wrote: However, sometimes using an index results in a HORRIBLE HORRIBLE plan. I recently encountered the issue myself, and plopping an ANALYZE $tablename in there, since I was using a temporary table anyway, make all the difference. The planner

Re: [PERFORM] Exhaustive list of what takes what locks

2011-02-02 Thread Nikolas Everett
Given that the a list would be difficult to maintain, is there some way I can make Postgres spit out the list of what locks are taken? --Nik On Wed, Feb 2, 2011 at 1:58 PM, Greg Smith g...@2ndquadrant.com wrote: Nikolas Everett wrote: Is there an exhaustive list of what takes what locks and

Re: [PERFORM] Are we in the ballpark?

2011-02-02 Thread John Rouillard
On Wed, Feb 02, 2011 at 10:06:53AM -0700, Wayne Conrad wrote: On 02/01/11 18:30, Greg Smith wrote: Bonnie++ (-f -n 0 -c 4) $PGDATA/xlog (RAID1) random seek: 369/sec block out: 87 MB/sec block in: 180 MB/sec $PGDATA (RAID10, 12 drives) random seek: 452 block out: 439 MB/sec block in: 881

Re: [PERFORM] Exhaustive list of what takes what locks

2011-02-02 Thread Nikolas Everett
On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett nik9...@gmail.com wrote: Given that the a list would be difficult to maintain, is there some way I can make Postgres spit out the list of what locks are taken? --Nik I just answered my own question - compile with -DLOCK_DEBUG in your

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
Greg Smith wrote: Given that even Oracle kicked out the RBO a long time ago, I'm not so sure longing for those good old days will go very far. I regularly see queries that were tweaked to always use an index run at 1/10 or less the speed of a sequential scan against the same data. The same

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Bruce Momjian
Mladen Gogala wrote: 2) The sort of random I/O done by index lookups can be as much as 50X as expensive on standard hard drives as sequential, if every block goes to physical hardware. Greg, how many questions about queries not using an index have you seen? There is a reason why

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Kenneth Marshall
On Wed, Feb 02, 2011 at 03:54:26PM -0500, Mladen Gogala wrote: Greg Smith wrote: Given that even Oracle kicked out the RBO a long time ago, I'm not so sure longing for those good old days will go very far. I regularly see queries that were tweaked to always use an index run at 1/10 or less

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Kevin Grittner
Mladen Gogala wrote: I'm 6'4, 235LBS so telling me that you disagree and that I am more stupid than a computer program, would not be a smart thing to do. Even if you had used a smiley there, that would have been incredibly inappropriate. I've never seen a computer program do anything so

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Robert Haas
On Wed, Feb 2, 2011 at 4:16 PM, Kevin Grittner kevin.gritt...@wicourts.gov wrote: Mladen Gogala  wrote: I'm 6'4, 235LBS so telling me that you disagree and that I am more stupid than a computer program, would not be a smart thing to do. Even if you had used a smiley there, that would have

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
Justin Pitts wrote: With all due respect, I consider myself smarter than the optimizer. I'm 6'4, 235LBS so telling me that you disagree and that I am more stupid than a computer program, would not be a smart thing to do. Please, do not misunderestimate me. I don't see computer programs

Re: [PERFORM] Exhaustive list of what takes what locks

2011-02-02 Thread Nikolas Everett
On Wed, Feb 2, 2011 at 3:29 PM, Nikolas Everett nik9...@gmail.com wrote: On Wed, Feb 2, 2011 at 2:53 PM, Nikolas Everett nik9...@gmail.com wrote: Given that the a list would be difficult to maintain, is there some way I can make Postgres spit out the list of what locks are taken? --Nik

[PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Dan Birken
I'm setting up a dedicated linux postgres box with 2x300GB 15k SAS drive in a RAID 1, though if future load dictates we would like to be able to upgrade to RAID 10. The hosting provider offers the following options for a RAID controller (all are the same price): ADAPTEC 3405 RAID Controller

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Greg Smith
Mladen Gogala wrote: Greg, how many questions about queries not using an index have you seen? There is a reason why people keep asking that. The sheer number of questions like that on this group should tell you that there is a problem there. There must be a relatively simple way of influencing

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Bruce Momjian
Greg Smith wrote: Mladen Gogala wrote: Greg, how many questions about queries not using an index have you seen? There is a reason why people keep asking that. The sheer number of questions like that on this group should tell you that there is a problem there. There must be a relatively

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Greg Smith
I direct anyone who thought Mladen was making a serious comment to http://www.nydailynews.com/news/politics/2009/01/08/2009-01-08_misunderestimate_tops_list_of_notable_bu-3.html if you want to get his little joke there. I plan to start using misunderestimate more in the future when talking

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Bruce Momjian
Andrew Dunstan wrote: On 02/02/2011 07:17 PM, Greg Smith wrote: I direct anyone who thought Mladen was making a serious comment to http://www.nydailynews.com/news/politics/2009/01/08/2009-01-08_misunderestimate_tops_list_of_notable_bu-3.html if you want to get his little joke

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Craig Ringer
On 03/02/11 07:15, Dan Birken wrote: However, they can't guarantee that any particular RAID controller would be in stock when they are building the machine, so basically I would like to know if any of these cards are sufficiently better or worse than the others that I should either a) wait

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Robert Haas
On Wed, Feb 2, 2011 at 7:03 PM, Greg Smith g...@2ndquadrant.com wrote: Given limited resources as a development community, it's hard to justify working on hinting--which has its own complexity to do right--when there are so many things that I think are more likely to help *everyone* that could

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Mladen Gogala
On 2/2/2011 7:03 PM, Greg Smith wrote: I think that's not quite the right question. For every person like yourself who is making an informed the optimizer is really picking the wrong index request, I think there are more who are asking for that but are not actually right that it will help. I

Re: [PERFORM] Server Configuration

2011-02-02 Thread Marcos Ortiz
On Wed, 2011-02-02 at 15:15 -0300, Cesar Arrieta wrote: Hi, I have a Server with Fedora Core 11, Tomcat and Postgresql 8.3. With Hardware: * 8GB RAM * 8 processors Intel Xeon E5520 @2.27GHz * 250GB SATA DISK Actually, it serves at most 250 connections. The problem happends when it serves

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Greg Smith
Dan Birken wrote: ADAPTEC 3405 RAID Controller ADAPTEC 4800 RAID Controller The 3405 and 4800 are two of Adaptec's older cards with only 128MB of cache on them. Those are on the slow side compared to the others listed. LSI MegaRaid 8308 RAID Controller ADAPTEC 5405 RAID Controller

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Scott Marlowe
On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith g...@2ndquadrant.com wrote: example.  Scott Marlowe was griping recently about a similar issue in some of the LSI models, too.  I suspect it's a problem impacting several of the larger RAID cards that use the big Intel IOP processors for their RAID

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Scott Marlowe
On Wed, Feb 2, 2011 at 7:00 PM, Craig Ringer cr...@postnewspapers.com.au wrote: Whatever RAID controller you get, make sure you have a battery backup unit (BBU) installed so you can safely enable write-back caching. Without that, you might as well use software RAID - it'll generally be faster

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Greg Smith
Scott Marlowe wrote: On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith g...@2ndquadrant.com wrote: example. Scott Marlowe was griping recently about a similar issue in some of the LSI models, too. I suspect it's a problem impacting several of the larger RAID cards that use the big Intel IOP

Re: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-02 Thread Greg Smith
Mladen Gogala wrote: The techies at big companies are the guys who will or will not make it happen. And these guys are not beginners. Appeasing them may actually go a long way. The PostgreSQL community isn't real big on appeasing people if it's at the expense of robustness or correctness,

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Dan Birken
Thank you everybody for the detailed answers, the help is well appreciated. A couple of follow-up questions: - Is the supercap + flash memory considered superior to the BBU in practice? Is that type of system well tested? - Is the linux support of the LSI and Adaptec cards comparable? -Dan On

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Scott Marlowe
On Wed, Feb 2, 2011 at 11:15 PM, Greg Smith g...@2ndquadrant.com wrote: Scott Marlowe wrote: On Wed, Feb 2, 2011 at 10:46 PM, Greg Smith g...@2ndquadrant.com wrote: example.  Scott Marlowe was griping recently about a similar issue in some of the LSI models, too.  I suspect it's a problem

Re: [PERFORM] Which RAID Controllers to pick/avoid?

2011-02-02 Thread Magnus Hagander
On Thu, Feb 3, 2011 at 07:30, Dan Birken bir...@gmail.com wrote: Thank you everybody for the detailed answers, the help is well appreciated. A couple of follow-up questions: - Is the supercap + flash memory considered superior to the BBU in practice? I think it's considered about equivalent.