>
>
> Without having at least compared EXPLAIN outputs from the two boxes, you
> have no business jumping to that conclusion.
>
> If EXPLAIN does show different plans, my first instinct would be to wonder
> whether the pg_stats data is equally up-to-date on both boxes.
>
> r
Robins Tharakan writes:
> 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...
Without having at least
On Fri, 9 Sep 2016 at 09:39 Andres Freund wrote:
> On 2016-09-07 23:37:31 +, 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.
>
> A
On 2016-09-07 23:37:31 +, 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
On Wed, Sep 7, 2016 at 4:37 PM, Robins Tharakan 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
On 8 Sep. 2016 7:38 am, "Robins Tharakan" 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 pos