Re: [PERFORM] pg_upgrade

2011-12-03 Thread Bruce Momjian
Bruce Momjian wrote: > Tory M Blue wrote: > > On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote: > > > > > Well, I am not totally clear how you are moving things around, but I do > > > know pg_upgrade isn't happy to have the old and new cluster be very > > > different. > > > > > > What I think

Re: [PERFORM] pg_upgrade

2011-12-03 Thread Bruce Momjian
Tory M Blue wrote: > On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote: > > > Well, I am not totally clear how you are moving things around, but I do > > know pg_upgrade isn't happy to have the old and new cluster be very > > different. > > > > What I think is happening is that you didn't prope

Re: [PERFORM] Question about VACUUM

2011-12-03 Thread Scott Marlowe
On Sat, Dec 3, 2011 at 6:11 AM, Ernesto Quiñones wrote: > Thanks for the answer Scott, actually my  autovacuum_naptime is 1h .. > but I don't find naptime parameter for a manual vacuum That's really high, but what I meant to as was what your vacuum_cost_delay was set to. Also vacuum_cost_limit.

Re: [PERFORM] pg_upgrade

2011-12-03 Thread Tory M Blue
On Sat, Dec 3, 2011 at 6:04 AM, Bruce Momjian wrote: > Well, I am not totally clear how you are moving things around, but I do > know pg_upgrade isn't happy to have the old and new cluster be very > different. > > What I think is happening is that you didn't properly move the > tablespace in the

Re: [PERFORM] Question about VACUUM

2011-12-03 Thread Kevin Grittner
Ernesto Quiñones wrote: > Scott Marlowe wrote: >> Ernesto Quiñones wrote: >>> I want to know if it's possible to predict (calculate), how long >>> a VACUUM FULL process will consume in a table? I don't think you said what version of PostgreSQL you're using. VACUUM FULL prior to version 9.0 i

Re: [PERFORM] manually force planner to use of index A vs index B

2011-12-03 Thread MirrorX
thx a lot for the reply. i will post the query plans when a new bulk insert will take place :) -- View this message in context: http://postgresql.1045698.n5.nabble.com/manually-force-planner-to-use-of-index-A-vs-index-B-tp5044616p5044691.html Sent from the PostgreSQL - performance mailing list ar

Re: [PERFORM] manually force planner to use of index A vs index B

2011-12-03 Thread Tomas Vondra
On 3.12.2011 15:34, MirrorX wrote: > > but, at some point there are some bulk inserts with a different date. when > this happens and i run the query mentioned above the planner is using index > A and not index B. > i guess this happens b/c the planner due to the last analyze statistics has > no va

[PERFORM] manually force planner to use of index A vs index B

2011-12-03 Thread MirrorX
hello to all, the situation i am facing is this-> table X-> 200 mil rows index A (date, columnA) index B (date,columnB,columnC) the query planner is working properly and for a specific query that selects from table X where all 3 columns of index B are set, it uses index B. but, at some point the

Re: [PERFORM] pg_upgrade

2011-12-03 Thread Bruce Momjian
Tory M Blue wrote: > So we are making progress on our performance issues, we are splitting > the data, changing the index value etc. So far having some success, > but we also want to test out some of the options and changes in the 9 > branch, but trying to dump and restore 750gb of data is not all

Re: [PERFORM] pg_upgrade

2011-12-03 Thread Klaus Ita
ever tried symlinking? On Dec 3, 2011 5:09 AM, "Tory M Blue" wrote: > So we are making progress on our performance issues, we are splitting > the data, changing the index value etc. So far having some success, > but we also want to test out some of the options and changes in the 9 > branch, but

Re: [PERFORM] Question about VACUUM

2011-12-03 Thread Ernesto Quiñones
Thanks for the answer Scott, actually my autovacuum_naptime is 1h .. but I don't find naptime parameter for a manual vacuum thanks again 2011/12/2 Scott Marlowe : > On Fri, Dec 2, 2011 at 8:32 PM, Ernesto Quiñones wrote: >> Hi friends >> >> I want to know if it's possible to predict (calculate)