| From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
|---|---|
| To: | Corey Taylor <corey(dot)taylor(dot)fl(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |
| Date: | 2019-09-23 22:51:12 |
| Message-ID: | 0d6e6bd8-20db-5902-f5eb-7130ff5543d0@aklaver.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 9/23/19 3:43 PM, Corey Taylor wrote:
> On Mon, Sep 23, 2019 at 4:50 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)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(dot)klaver(at)aklaver(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Corey Taylor | 2019-09-23 22:56:52 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |
| Previous Message | Corey Taylor | 2019-09-23 22:43:03 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |