Re: psql is hanging

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: localdevjs(at)gmail(dot)com
Cc: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: psql is hanging
Date: 2018-12-02 23:34:03
Message-ID: CAFNqd5WfhWYzFhdg2iQmNDnBX9V_xyE_Ud8akb=_roGBg8BSfA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I like the "add an analyze" idea; the two most likely causes of the
phenomenon (to my mind) are either:

a) Something's getting locked and Tom Lane's idea of checking pg_locks
when you notice it's stopped can help track down the problem.

Further to that, the thing I'd be expecting to see if the problem is
locking is that the connection that's blocked up will be waiting on a
lock held by another connection.

It's near certain that you'll find that the connection doing the work
will have LOTS of locks outstanding; that's not a problem at all;
that's perfectly normal. You need to look keenly for locks that have
not yet been granted.

b) I find it common in my environments to need to do manual ANALYZE
requests all the time because I'll set up temporary tables (that the
autovacuum daemon can't do anything about) which, as the stats are
lacking, will lead to awful query plans that make queries run badly.

If you use temporary tables, that's like a heavy "thumb on the scale"
that can lead to awful performance, unless those tables get an ANALYZE
after getting populated.

Unpredictable slowness can certainly result from tables having changed
size leading to pathological query plans. ANALYZE will help.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Glenn Schultz 2018-12-03 07:06:29 using a function in where
Previous Message Igor Korot 2018-12-02 13:24:49 Re: How to watch for schema changes