Re: [PERFORM] Running PostgreSQL as fast as possible no matter the consequences

2011-01-25 Thread Bruce Momjian
Robert Haas wrote: > On Wed, Jan 19, 2011 at 12:07 PM, Bruce Momjian wrote: > > Chris Browne wrote: > >> gentosa...@gmail.com (A B) writes: > >> > If you just wanted PostgreSQL to go as fast as possible WITHOUT any > >> > care for your data (you accept 100% dataloss and datacorruption if any > >>

Re: [PERFORM] Queries becoming slow under heavy load

2011-01-25 Thread Ing. Marcos Ortiz Valmaseda
When you say that with a lot of concurrent access, queries get very slow, How many concurrent connections to your server have you had? more that max_connections´value? If you want to have many concurrent connections, you should have consider to use a pooling connection system like pgbouncer or p

Re: [PERFORM] Queries becoming slow under heavy load

2011-01-25 Thread Kevin Grittner
"Anne Rosset" wrote: > We are running some performances tests. With a lot of concurrent > access, queries get very slow. When there is no load, those > queries run fast. What's "a lot"? > We kind of see a trend about these queries: it seems like the > ones that become very slow have an ORD

Re: [PERFORM] Queries becoming slow under heavy load

2011-01-25 Thread Andy Colson
On 1/25/2011 3:37 PM, Anne Rosset wrote: Hi, We are running some performances tests. With a lot of concurrent access, queries get very slow. When there is no load, those queries run fast. We kind of see a trend about these queries: it seems like the ones that become very slow have an ORDER BY o

[PERFORM] Queries becoming slow under heavy load

2011-01-25 Thread Anne Rosset
Hi, We are running some performances tests. With a lot of concurrent access, queries get very slow. When there is no load, those queries run fast. We kind of see a trend about these queries: it seems like the ones that become very slow have an ORDER BY or MAX in them. Here are our config s

Re: [PERFORM] Bloat issue on 8.3; autovac ignores HOT page splits?

2011-01-25 Thread Mark Kirkwood
On 26/01/11 07:28, Josh Berkus wrote: One question: in 8.3 and earlier, is the FSM used to track dead_rows for pg_stat_user_tables? If I'm understanding you correctly, ANALYZE is the main guy tracking/updating the dead row count. regards Mark -- Sent via pgsql-performance mailing list (p

Re: [PERFORM] Bloat issue on 8.3; autovac ignores HOT page splits?

2011-01-25 Thread Josh Berkus
> Can we see those stats again with n_tup_ins/upd/del? Sure: -[ RECORD 2 ]--+-- schemaname | public relname| general_info n_dead_tup | 12 n_live_tup | 1 n_tup_upd | 8817 n_tup_del |

Re: [PERFORM] Bloat issue on 8.3; autovac ignores HOT page splits?

2011-01-25 Thread Robert Haas
On Mon, Jan 24, 2011 at 9:26 PM, Josh Berkus wrote: > It looks to me like autovacuum doesn't ever consider when HOT updates > lead to page splits, and so require vacuuming.  Or am I diagnosing it wrong? I'm not sure what you mean by a page split. An update wherein the new heap tuple won't fit on

Re: [PERFORM] Fun little performance IMPROVEMENT...

2011-01-25 Thread Ivan Voras
On 21/01/2011 19:12, gr...@amadensor.com wrote: I was doing a little testing to see how machine load affected the performance of different types of queries, index range scans, hash joins, full scans, a mix, etc. In order to do this, I isolated different performance hits, spinning only CPU, loadi

Re: [PERFORM] Possible to improve query plan?

2011-01-25 Thread Cédric Villemain
2011/1/25 Kevin Grittner : > Jeremy Palmer wrote: > >> Kevin I've now clustered the table. And the performance did >> increase quite a bit. > > Yeah, that's enough to notice the difference. > >> My only question is how often will I need to re-cluster the table, >> because it comes at quite a cost.