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

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: Robins Tharakan <tharakan(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: High-CPU consumption on information_schema (only) query
Date: 2016-09-08 11:04:27
Message-ID: CAMsr+YHecqZZJcxTs9z9K47mkaaa3mEkt4N+_pbSVEJh9D7RyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8 Sep. 2016 7:38 am, "Robins Tharakan" <tharakan(at)gmail(dot)com> wrote:
>
> Hi,
>
> An SQL (with only information_schema related JOINS) when triggered, runs
with max CPU (and never ends - killed after 2 days).
> - It runs similarly (very slow) on a replicated server that acts as a
read-only slave.
> - Top shows only postgres as hitting max CPU (nothing else). When query
killed, CPU near 0%.
> - When the DB is restored on a separate test server (with the exact
postgresql.conf) the same query works fine.
> - There is no concurrent usage on the replicated / test server (although
the primary is a Production server and has concurrent users).
>
> Questions:
> - If this was a postgres bug or a configuration issue, query on the
restored DB should have been slow too. Is there something very basic I am
missing here?
>
> If someone asks for I could provide SQL + EXPLAIN, but it feels
irrelevant here. I amn't looking for a specific solution but what else
should I be looking for here?

Get a series of stack traces.

Perf with stack output would be good too.

You need debug info for both.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-09-08 11:10:23 Re: \timing interval
Previous Message Etsuro Fujita 2016-09-08 10:55:03 Re: Push down more UPDATEs/DELETEs in postgres_fdw