Re: [PERFORM] "global/pgstat.stat" corrupt

2012-06-22 Thread David Kerr
On Fri, Jun 22, 2012 at 03:49:00PM -0400, Tom Lane wrote: - David Kerr writes: - > I just restored a DB from a cold backup (pg_ctl stop -m fast) - - > When starting the DB I see: - > LOG: corrupted statistics file "global/pgstat.stat" - - Is that repeatable? It wouldn't be too surprising to se

Re: [PERFORM] "global/pgstat.stat" corrupt

2012-06-22 Thread Tom Lane
David Kerr writes: > I just restored a DB from a cold backup (pg_ctl stop -m fast) > When starting the DB I see: > LOG: corrupted statistics file "global/pgstat.stat" Is that repeatable? It wouldn't be too surprising to see this once when starting from a filesystem backup, if you'd managed to

[PERFORM] "global/pgstat.stat" corrupt

2012-06-22 Thread David Kerr
Howdy, I just restored a DB from a cold backup (pg_ctl stop -m fast) When starting the DB I see: LOG: corrupted statistics file "global/pgstat.stat" When I look at the filesystem I don't see a global/pgstat.stat file but i do see a pg_stat_tmp/pgstat.stat is that PG rebuilding the corrupt fi

Re: [PERFORM] Drop statistics?

2012-06-22 Thread David Kerr
On Fri, Jun 22, 2012 at 01:27:51PM -0400, Tom Lane wrote: - David Kerr writes: - > I'm trying to work through a root cause on a performance problem. I'd like to - > be able to "show" that a problem was fixed by analyzing the table. - - > what i've done is - > set default_statistics_target=1 - >

Re: [PERFORM] Drop statistics?

2012-06-22 Thread Tom Lane
David Kerr writes: > I'm trying to work through a root cause on a performance problem. I'd like to > be able to "show" that a problem was fixed by analyzing the table. > what i've done is > set default_statistics_target=1 > analyze > That gets rid of most of the rows in pg_stats, but i'm still

[PERFORM] Drop statistics?

2012-06-22 Thread David Kerr
I'm trying to work through a root cause on a performance problem. I'd like to be able to "show" that a problem was fixed by analyzing the table. what i've done is set default_statistics_target=1 analyze That gets rid of most of the rows in pg_stats, but i'm still getting decent performance. I

Re: [PERFORM] Why is a hash join being used?

2012-06-22 Thread Kevin Grittner
Tim Jacobs wrote: > The nested loop join performs very quickly, whereas the hash join > is incredibly slow. If I disable the hash join temporarily then a > nested loop join is used in the second case and is the query runs > much more quickly. How can I change my configuration to favor the > nest