| 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-24 00:28:46 |
| Message-ID: | CADBz3868gUM2TL25svb6x8UWWEEh21msf1zdFqNiSukzZEry_w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Sep 23, 2019 at 7:23 PM Adrian Klaver <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.
I guess the length of the query when before/during the ANALZYE felt like
something more was wrong.
corey
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adrian Klaver | 2019-09-24 00:58:19 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |
| Previous Message | Adrian Klaver | 2019-09-24 00:23:27 | Re: postgres 9.6: insert into select finishes only in pgadmin not psql |