Re: postgres 9.6: insert into select finishes only in pgadmin notpsql
От | Adrian Klaver |
---|---|
Тема | Re: postgres 9.6: insert into select finishes only in pgadmin notpsql |
Дата | |
Msg-id | 0d6e6bd8-20db-5902-f5eb-7130ff5543d0@aklaver.com обсуждение исходный текст |
Ответ на | Re: postgres 9.6: insert into select finishes only in pgadmin not psql (Corey Taylor <corey.taylor.fl@gmail.com>) |
Ответы |
Re: postgres 9.6: insert into select finishes only in pgadmin not psql
|
Список | pgsql-general |
On 9/23/19 3:43 PM, Corey Taylor wrote: > On Mon, Sep 23, 2019 at 4:50 PM Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> wrote: > > Smaller hammer: > > https://www.postgresql.org/docs/11/sql-createtable.html#SQL-CREATETABLE-STORAGE-PARAMETERS > > "autovacuum_enabled, toast.autovacuum_enabled (boolean)" > > which can be done by ALTER TABLE also: > > https://www.postgresql.org/docs/11/sql-altertable.html > > > > Thanks for the feedback. I think we'll be able to work around this > issue in a way that is reliable enough to script. > > I am curious if this is a "known" issue with restoring tables and > analyze running at some point after while performing a select on the > tables. It would be kind of nice to know when to predict this kind of > situation. Usually what is seen here is the opposite, that tables are restored and ANALYZE is not run and performance on the subsequent queries is poor due to lack of current statistics. What is the restore process? > > corey -- Adrian Klaver adrian.klaver@aklaver.com
В списке pgsql-general по дате отправления: