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
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 |