Re: postgres 9.6: insert into select finishes only in pgadmin notpsql
От | Adrian Klaver |
---|---|
Тема | Re: postgres 9.6: insert into select finishes only in pgadmin notpsql |
Дата | |
Msg-id | 7830f74b-f4cf-ece2-c088-52c2f621e6aa@aklaver.com обсуждение исходный текст |
Ответ на | Re: postgres 9.6: insert into select finishes only in pgadmin not psql (Corey Taylor <corey.taylor.fl@gmail.com>) |
Список | pgsql-general |
On 9/23/19 5:28 PM, Corey Taylor wrote: > On Mon, Sep 23, 2019 at 7:23 PM Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.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.klaver@aklaver.com
В списке pgsql-general по дате отправления: