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 21:50:55 |
Message-ID: | ad7b0fa3-2502-f711-6237-72eb06e0f355@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 9/23/19 2:34 PM, Corey Taylor wrote:
> On Mon, Sep 23, 2019 at 4:31 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> Hmm, are there triggers on wss_entries that are UPDATEing/DELETEing
> entries elsewhere?
>
>
> No, that table is pretty much stand-alone. What we're seeing here is
> most likely caused by the initial copy of the legacy db tables.
>
> This happens when creating the local test db which I do right before the
> tests. I can avoid the issue if I monitor top and wait for the analyze
> to complete on all the related tables.
Big hammer approach:
alter system set autovacuum = off;
SELECT pg_reload_conf();
Do work
alter system reset autovacuum;
SELECT pg_reload_conf();
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
>
> corey
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Corey Taylor | 2019-09-23 22:43:03 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |
Previous Message | Corey Taylor | 2019-09-23 21:34:57 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |