Here is my log analysis:
Due to a database recovery task it appears that:
I stopped postgresql
I started postgresql (and as default autovacuum daemon)
I restored the databases (need to restore 4 databases)
It seems that after database 1 have been restored, autovacumm
started on it and has been stopped while restoring database 2.
@see log as attached
Here is backup/restore commands i use:
/usr/bin/pg_dump -i -h localhost -U postgres -F c -b -f ... x 4 times
sudo -u postgres pg_restore -d 'database1' x 4 times
Does this kind of error can lead to the query problem ?
If so, what would you suggest me to do to avoid the problem again ?.
Thanks
Lionel
Kevin Grittner a écrit :
lionel duboeuf wrote:
Kevin Grittner a écrit :
I just reread your original email, and I'm not sure I understand
what you meant regarding VACUUM ANALYZE. If you run that right
beforehand, do you still get the slow plan for user 10?
I confirm by executing manual "VACUUM ANALYZE" that the problem is
solved. But what i don't understand is that i would expect
autovacuum to do the job.
I think this is the crux of the issue. Boosting the
default_statistics_target or the statistics target for specific
columns might help, reducing autovacuum_analyze_scale_factor might
help, but I can't help wondering whether you inserted a large number
of rows for user 10 and then ran the query to select user 10 before
autovacuum had time to complete. Does that seem possible?
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
