Re: [PERFORM] Configuration for a new server.

2011-02-01 Thread Greg Smith
Benjamin Krajmalnik wrote: have a new set of servers coming in -- Dual Xeon E5620's, 96GB RAM, 18 spindles (1 RAID1 for OS -- SATA, 12 disk RAID10 for data -- SAS, RAID-1 for logs -- SAS, 2 hot spares SAS). You didn't mention the RAID controller and its cache setup. That's a critical

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Lew
Please reply to the list with list business. On 01/31/2011 03:22 PM, Mladen Gogala wrote: On 1/31/2011 7:28 AM, Lew wrote: That seems a little harsh. Oh? How so? You post to a discussion group but want to suppress discussion? No, I just want to stick to the subject. My motivation for doing

Re: [PERFORM] Configuration for a new server.

2011-02-01 Thread Benjamin Krajmalnik
Greg, Thank you very much for your quick response. The servers are using Areca 1600 series controllers with battery backup and 2GB cache. I really enjoyed your book (actually, both of the books your company published). Found them extremely helpful and they filled a lot of gaps in my

Re: [PERFORM] Configuration for a new server.

2011-02-01 Thread Benjamin Krajmalnik
There are approximately 50 tables which get updated with almost 100% records updated every 5 minutes - what is a good number of autovacuum processes to have on these? The current server I am replacing only has 3 of them but I think I may gain a benefit from having more. Watch

Re: [PERFORM] postgres 9 query performance

2011-02-01 Thread Ross J. Reedstrom
On Sun, Jan 30, 2011 at 05:18:15PM -0500, Tom Lane wrote: Andres Freund and...@anarazel.de writes: What happens if you change the left join event.origin on event.id = origin.eventid into join event.origin on event.id = origin.eventid ? The EXISTS() requires that origin is

[PERFORM] Exhaustive list of what takes what locks

2011-02-01 Thread Nikolas Everett
Dear list, 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. You can reproduce it like so: First: DROP TABLE IF

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Greg Smith
Mladen Gogala wrote: Did anyone try using shake while the cluster is active? Any problems with corruption or data loss? I ran the thing on my home directory and nothing was broken. I didn't develop any performance test, so cannot vouch for the effectiveness of the procedure. Did anyone play

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Jon Nelson
On Tue, Feb 1, 2011 at 1:24 PM, Greg Smith g...@2ndquadrant.com wrote: Mladen Gogala wrote: Did anyone try using shake while the cluster is active? Any problems with corruption or data loss? I ran the thing on my home directory and nothing was broken. I didn't develop any performance test, so

Re: [PERFORM] Questions on query planner, join types, and work_mem

2011-02-01 Thread Bruce Momjian
Bruce Momjian wrote: Robert Haas wrote: On Wed, Aug 11, 2010 at 9:42 PM, Bruce Momjian br...@momjian.us wrote: This confused me. ?If we are assuing the data is in effective_cache_size, why are we adding sequential/random page cost to the query cost routines? See the comments for

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Grant Johnson
Instead of something like 'shake' (which more or less works, even though it doesn't use fallocate and friends) I frequently use either CLUSTER (which is what Greg Smith is suggesting) or a series of ALTER TABLE ... ALTER COLUMN... which rewrites the table. With PG 9 perhaps VACUUM FULL is more

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Robert Haas
On Tue, Feb 1, 2011 at 3:31 PM, Grant Johnson gr...@amadensor.com wrote: Does vacuum full rewrite the whole table, or only the blocks with free space? The whole table. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance

Re: [PERFORM] Bloat issue on 8.3; autovac ignores HOT new pages?

2011-02-01 Thread Mark Kirkwood
On 01/02/11 10:57, Scott Marlowe wrote: On Mon, Jan 31, 2011 at 11:27 AM, Josh Berkusj...@agliodbs.com wrote: Robert, Mark, I have not been able to reproduce this issue in a clean test on 9.0. As a result, I now think that it was related to the FSM being too small on the user's 8.3 instance,

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

2011-02-01 Thread Mladen Gogala
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 really plan for world domination this needs to be part of it. There are many

Re: [PERFORM] Any experience using shake defragmenter?

2011-02-01 Thread Mark Kirkwood
On 31/01/11 17:38, Mladen Gogala wrote: Mark Felder wrote: Why do you feel the need to defrag your *nix box? Let's stick to the original question and leave my motivation for some other time. Have you used the product? If you have, I'd be happy to hear about your experience with it.

[PERFORM] Are we in the ballpark?

2011-02-01 Thread Wayne Conrad
We're building a new database box. With the help of Gregory Smith's book, we're benchmarking the box: We want to know that we've set it up right, we want numbers to go back to if we have trouble later, and we want something to compare our _next_ box against. What I'd like to know is, are the

Re: [PERFORM] Configuration for a new server.

2011-02-01 Thread Greg Smith
Benjamin Krajmalnik wrote: There are approximately 50 tables which get updated with almost 100% records updated every 5 minutes -- what is a good number of autovacuum processes to have on these? The current server I am replacing only has 3 of them but I think I may gain a benefit from

Re: [PERFORM] Are we in the ballpark?

2011-02-01 Thread Greg Smith
Wayne Conrad wrote: We're building a new database box. With the help of Gregory Smith's book, we're benchmarking the box: We want to know that we've set it up right, we want numbers to go back to if we have trouble later, and we want something to compare our _next_ box against. Do you not

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

2011-02-01 Thread Samuel Gendler
On Tue, Feb 1, 2011 at 3:44 PM, Mladen Gogala mladen.gog...@vmsinfo.comwrote: 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: [HACKERS] [PERFORM] Slow count(*) again...

2011-02-01 Thread Mladen Gogala
Samuel Gendler wrote: Don't listen to him. He's got an oracle bias. And bad sinuses, too. Slashdot already announced that NoSQL is actually going to dominate the world, so postgres has already lost that battle. Everything postgres devs do now is just an exercise in relational

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

2011-02-01 Thread Samuel Gendler
On Tue, Feb 1, 2011 at 7:40 PM, Mladen Gogala mladen.gog...@vmsinfo.comwrote: Samuel Gendler wrote: Don't listen to him. He's got an oracle bias. And bad sinuses, too. Slashdot already announced that NoSQL is actually going to dominate the world, so postgres has already lost that