Re: [PERFORM] Anyone running on RHEL Cluster?

2007-12-28 Thread Mikko Partio
On Dec 26, 2007 7:36 PM, Chris Hoover [EMAIL PROTECTED] wrote: Is anyone running their production PostgreSQL server on the RHEL Cluster software? If so, how is it working for you? My linux admin is looking at trying to increase the robustness of our environment and wanting to try and

Re: [PERFORM] [Again] Postgres performance problem

2007-09-12 Thread Mikko Partio
On 9/12/07, Scott Marlowe [EMAIL PROTECTED] wrote: On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's easy for them to seriously bloat. Reindex is done everyday after VACUUM FULL VERBOSE ANALYZE. I save also

Re: [PERFORM] Vacum Analyze problem

2007-09-04 Thread Mikko Partio
On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello everyone: I wanted to ask you about how the VACUUM ANALYZE works. is it possible that something can happen in order to reset its effects forcing to execute the VACUUM ANALYZE comand again? Yes, lots of modifications

Re: [PERFORM] 8.2 Autovacuum BUG ?

2007-08-31 Thread Mikko Partio
On 8/31/07, Alvaro Herrera [EMAIL PROTECTED] wrote: Pallav Kalva wrote: Tom Lane wrote: Probably represents freezing of old tuples, which is a WAL-logged operation as of 8.2. Is it likely that the data is 200M transactions old? If nothing changed on these tables how can it freeze

Re: [PERFORM] Slow indexscan

2007-06-25 Thread Mikko Partio
On 6/20/07, Tom Lane [EMAIL PROTECTED] wrote: There's no obvious reason for the previous query to be so slow, unless you've got horrendously slow or overloaded disk hardware. What sort of machine is this anyway, and was it doing any other work at the time? Granted it is doing other work

[PERFORM] Slow indexscan

2007-06-20 Thread Mikko Partio
Hello group I have a problem with a simple index scan using the primary key of a table taking too long. Relevant facts: pg version 7.3.4 (yeah very old, we are upgrading asap) postgresql.conf: shared_buffers = 25000 random_page_cost = 2 effective_cache_size = 20 sort_mem = 2 Table:

Re: [PERFORM] Slow indexscan

2007-06-20 Thread Mikko Partio
On 6/20/07, Tom Lane [EMAIL PROTECTED] wrote: Mikko Partio [EMAIL PROTECTED] writes: Index Scan using tbl_20070601_pkey on tbl_20070601 t1 (cost=0.00..365.13rows=13 width=137) (actual time= 120.83..10752.64 rows=539 loops=1) Index Cond: ((validtime = 2007060200::bigint

Re: [PERFORM] Slow indexscan

2007-06-20 Thread Mikko Partio
On 6/20/07, Tom Lane [EMAIL PROTECTED] wrote: Mikko Partio [EMAIL PROTECTED] writes: Adding a new index does not speed up the query (although the planner decides to use the index): Hm. Lots of dead rows maybe? What's your vacuuming policy? regards, tom lane