Re: High-CPU consumption on information_schema (only) query

Поиск
Список
Период
Сортировка
От Robins Tharakan
Тема Re: High-CPU consumption on information_schema (only) query
Дата
Msg-id CAEP4nAx8y9K-mb3CxMPP9ty-L9sLaBNhrR4LJKgcXbXkGxP00g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: High-CPU consumption on information_schema (only) query  (Andres Freund <andres@anarazel.de>)
Ответы Re: High-CPU consumption on information_schema (only) query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
On Fri, 9 Sep 2016 at 09:39 Andres Freund <andres@anarazel.de> wrote:
On 2016-09-07 23:37:31 +0000, Robins Tharakan wrote:
> If someone asks for I could provide SQL + EXPLAIN, but it feels irrelevant
> here.

Why is that? information_schema are normal sql queries, and some of them
far from trivial.

Andres
Hi Andres,

I completely agree. With 'irrelevant' I was only trying to imply that irrespective of the complexity of the query, a replicated box was seeing similar slowness whereas a Restored DB wasn't. It felt that the SQL itself isn't to blame here...

In effect, I was trying to ask if I am forgetting / missing something very obvious / important that could cause such an observation.

As others recommended, I am unable to have direct access to the production (master / slave) instances and so GDB / stack trace options are out of bounds at this time. I'll revert if I am able to do that.

-
thanks
robins


 
--

-
robins

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Use LEFT JOINs in some system views in case referenced row doesn
Следующее
От: Tom Lane
Дата:
Сообщение: Re: High-CPU consumption on information_schema (only) query