Re: Almost infinite query -> Different Query Plan when changing where clause value
От | lionel duboeuf |
---|---|
Тема | Re: Almost infinite query -> Different Query Plan when changing where clause value |
Дата | |
Msg-id | 4B7A72CA.2030305@boozter.com обсуждение исходный текст |
Ответ на | Re: Almost infinite query -> Different Query Plan when changing where clause value ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Список | pgsql-performance |
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 > >
В списке pgsql-performance по дате отправления: