Re: [PERFORM] PostgreSQL 9.2.3 performance problem caused Exclusive locks

I am having the same exact problems. I reduced shared buffers as that seems to have done the trick for now in this thread. If things improve I'll post back and confirm. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PostgreSQL-9-2-3-performance-problem-caused-Exclusi

Re: [PERFORM] Slow CTE Query

On Sat, May 18, 2013 at 12:54 PM, Stefan Keller wrote: > I'm experiencing a very slow CTE query (see below). > > When I split the three aggregations into three separate views, its' decent > fast. So I think it's due to the planner. > > Any ideas like reformulating the query? Rewrite it without CT

[PERFORM] Slow CTE Query

Hi, I'm experiencing a very slow CTE query (see below). When I split the three aggregations into three separate views, its' decent fast. So I think it's due to the planner. Any ideas like reformulating the query? These are the tables and views involved: * Table promotion with start/end date and

[PERFORM]

Hi, I'm experiencing a very slow CTE query (see below). When I split the three aggregationns into separate views, its' decent fast. So I think it's due to the planner. Any ideas how to reformulate the query? These are the tables and views involved: * Table promotion with start/end date and a re

Re: [PERFORM] statistics target for columns in unique constraint?

Thanks guys! I'm gonna try tuning the statistics back down to 10 on that table and see what that does to the insertion rates. Oh and for Mark: Not to worry - i'd actually tuned the stats there up myself awhile ago in an experiment to see if -that- would've sped insertions some; back before i'd h

Re: [PERFORM] Deleting Rows From Large Tables

Analyze your temp tables after filling and before using! 17 трав. 2013 17:27, "Sékine Coulibaly" напис. > Oh, sorry, overlooked that part. > Maybe refreshing stats with VACUUM FULL ? > > > 2013/5/17 Robert Emery > >> Hi Sékine, >> >> Unfortunately I'm not trying to empty the table completely, ju