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:58:19
Message-ID: 7830f74b-f4cf-ece2-c088-52c2f621e6aa@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/23/19 5:28 PM, Corey Taylor wrote:
> On Mon, Sep 23, 2019 at 7:23 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> "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?
>
>
> There are several other restore called and a delete query that clears
> out an unrelated table.
>
> However, I think this solves the issue for us and the mystery. The
> ANALYZE was missing which reduces an unending query down to a minute.
> The ANALZYE runs very quickly on its own so we're simply going to fix
> the issue by following documented advice.

Aah, so it was the common case. Order is restored to the Postgres Universe:)

>
> I guess the length of the query when before/during the ANALZYE felt like
> something more was wrong.
>
> corey

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Gierth 2019-09-24 02:40:12 Re: How to get timezone offset in timestamp with time zone AT TIME ZONE output.
Previous Message Corey Taylor 2019-09-24 00:28:46 Re: postgres 9.6: insert into select finishes only in pgadmin not psql