Re: High-CPU consumption on information_schema (only) query - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: High-CPU consumption on information_schema (only) query
Date
Msg-id CAMsr+YHecqZZJcxTs9z9K47mkaaa3mEkt4N+_pbSVEJh9D7RyA@mail.gmail.com
Whole thread Raw
In response to High-CPU consumption on information_schema (only) query  (Robins Tharakan <tharakan@gmail.com>)
List pgsql-hackers
<p dir="ltr"><p dir="ltr">On 8 Sep. 2016 7:38 am, "Robins Tharakan" <<a
href="mailto:tharakan@gmail.com">tharakan@gmail.com</a>>wrote:<br /> ><br /> > Hi,<br /> ><br /> > An
SQL(with only information_schema related JOINS) when triggered, runs with max CPU (and never ends - killed after 2
days).<br/> > - It runs similarly (very slow) on a replicated server that acts as a read-only slave.<br /> > -
Topshows only postgres as hitting max CPU (nothing else). When query killed, CPU near 0%.<br /> > - When the DB is
restoredon a separate test server (with the exact postgresql.conf) the same query works fine.<br /> > - There is no
concurrentusage on the replicated / test server (although the primary is a Production server and has concurrent
users).<br/> ><br /> > Questions:<br /> > - If this was a postgres bug or a configuration issue, query on the
restoredDB should have been slow too. Is there something very basic I am missing here?<br /> ><br /> > If someone
asksfor I could provide SQL + EXPLAIN, but it feels irrelevant here. I amn't looking for a specific solution but what
elseshould I be looking for here? <p dir="ltr">Get a series of stack traces.<p dir="ltr">Perf with stack output would
begood too.<p dir="ltr">You need debug info for both. 

pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Push down more UPDATEs/DELETEs in postgres_fdw
Next
From: Craig Ringer
Date:
Subject: Re: \timing interval