Re: postgres 9.6: insert into select finishes only in pgadmin not psql

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-24 00:23:27
Message-ID: ce9ad78e-1f5a-332a-ba10-fc58de987dd7@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/23/19 3:56 PM, Corey Taylor wrote:
> On Mon, Sep 23, 2019 at 5:51 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> 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?
>
>
> For these specific legacy db tables, they are isolated in a separate
> schema.  We then use pg_restore to restore the entire schema.
> Essentially just:
>
> pg_restore -n wss --no-owner

Per my previous post and below, the above does not kick off an ANALYZE:

https://www.postgresql.org/docs/11/app-pgrestore.html

"Once restored, it is wise to run ANALYZE on each restored table so the
optimizer has useful statistics; see Section 24.1.3 and Section 24.1.6
for more information."

So is there some other step in the process that occurs after the restore
and before you run your function?

>
> corey

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Corey Taylor 2019-09-24 00:28:46 Re: postgres 9.6: insert into select finishes only in pgadmin not psql
Previous Message Corey Taylor 2019-09-23 22:56:52 Re: postgres 9.6: insert into select finishes only in pgadmin not psql