| From: | Corey Taylor <corey(dot)taylor(dot)fl(at)gmail(dot)com> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(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:43:03 |
| Message-ID: | CADBz384k+ugWNODy80cU1qE6X0rzDHHuxqxihn-q1e9xFxm79g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Sep 23, 2019 at 4:50 PM Adrian Klaver <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.
corey
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2019-09-23 22:51:12 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |
| Previous Message | Adrian Klaver | 2019-09-23 21:50:55 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |