Re: postgres 9.6: insert into select finishes only in pgadmin notpsql - Mailing list pgsql-general

From Adrian Klaver
Subject Re: postgres 9.6: insert into select finishes only in pgadmin notpsql
Date
Msg-id 0d6e6bd8-20db-5902-f5eb-7130ff5543d0@aklaver.com
Whole thread Raw
In response to Re: postgres 9.6: insert into select finishes only in pgadmin not psql  (Corey Taylor <corey.taylor.fl@gmail.com>)
Responses Re: postgres 9.6: insert into select finishes only in pgadmin not psql
List 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 by date:

Previous
From: Corey Taylor
Date:
Subject: Re: postgres 9.6: insert into select finishes only in pgadmin not psql
Next
From: Corey Taylor
Date:
Subject: Re: postgres 9.6: insert into select finishes only in pgadmin not psql