Date: Mon, 7 Feb 2022 11:09:27 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Lars Aksel Opsahl <Lars.Opsahl@nibio.no>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: slow "select count(*) from information_schema.tables;" in some
 cases
Message-ID: <20220207170927.GF31460@telsasoft.com>
References: 
 <AM7P189MB1028F684ADED9D89722C85C19D2C9@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <AM7P189MB1028F684ADED9D89722C85C19D2C9@AM7P189MB1028.EURP189.PROD.OUTLOOK.COM>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220207170927.GF31460%40telsasoft.com>
Precedence: bulk

On Mon, Feb 07, 2022 at 04:56:35PM +0000, Lars Aksel Opsahl wrote:
> Sometimes simple sql's like this takes a very long time  "select count(*) from information_schema.tables;"
> 
> Other sql's not including system tables may work ok but login also takes a very long time.
> 
> The CPU load on the server is around 25%. There is no iowait.
> 
> This happens typically when we are running many functions in parallel creating many temp tables and unlogged tables I think.
> 
> Here is a slow one:
> https://explain.depesz.com/s/tUt5
> 
> and here is fast one :
> https://explain.depesz.com/s/yYG4

The only difference is that this is sometimes many times slower.

 Finalize Aggregate  (cost=42021.15..42021.16 rows=1 width=8) (actual time=50602.755..117201.768 rows=1 loops=1)
   ->  Gather  (cost=42020.94..42021.15 rows=2 width=8) (actual time=130.527..117201.754 rows=3 loops=1)
         Workers Planned: 2
         Workers Launched: 2

> Here are my settings (the server has around 256 GB og memory) :

What version of postgres ?  What OS/version ?
https://wiki.postgresql.org/wiki/Slow_Query_Questions

Are there any server logs around that time ?
Or session logs for the slow query ?

Is it because the table creation is locking (rows of) various system catalogs ?
I'm not sure if it'd be a single, long delay that you could see easily with
log_lock_waits, or a large number of small delays, maybe depending on whether
your table creation is done within a transaction.

-- 
Justin