Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iCUG8-0004a5-Ng for pgsql-performance@arkaria.postgresql.org; Mon, 23 Sep 2019 19:44:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iCUG6-0004Fl-Nm for pgsql-performance@arkaria.postgresql.org; Mon, 23 Sep 2019 19:44:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iCUG6-00048A-DA for pgsql-performance@lists.postgresql.org; Mon, 23 Sep 2019 19:44:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iCUG2-00072N-Tn for pgsql-performance@lists.postgresql.org; Mon, 23 Sep 2019 19:44:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x8NJiNxh017617; Mon, 23 Sep 2019 15:44:23 -0400 From: Tom Lane To: =?UTF-8?Q?Lu=c3=ads_Roberto_Weck?= cc: pgsql-performance@lists.postgresql.org Subject: Re: Slow query on V12. In-reply-to: References: <13d5836f-27c0-d8c3-0106-6ba0160fcd2b@siscobra.com.br> Comments: In-reply-to =?UTF-8?Q?Lu=c3=ads_Roberto_Weck?= message dated "Mon, 23 Sep 2019 16:12:02 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <17615.1569267863.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Mon, 23 Sep 2019 15:44:23 -0400 Message-ID: <17616.1569267863@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk =?UTF-8?Q?Lu=c3=ads_Roberto_Weck?= writes: > This is the query that is actually slow: > -- EXPLAIN (ANALYZE, COSTS, VERBOSE, BUFFERS) > SELECT table_schema, table_name, >        n_live_tup::numeric as est_rows, >        pg_table_size(relid)::numeric as table_size >   FROM information_schema.columns >        JOIN pg_stat_user_tables as psut ON table_schema = > psut.schemanameAND table_name = psut.relname >        LEFT JOIN pg_statsON table_schema = pg_stats.schemanameAND > table_name = pg_stats.tablenameAND column_name = attname >  WHERE attname IS NULL >    AND table_schema NOT IN ('pg_catalog', 'information_schema') >  GROUP BY table_schema, table_name, relid, n_live_tup As a rule of thumb, mixing information_schema views and native PG catalog accesses in one query is a Bad Idea (TM). There are a number of reasons for this, some of which have been alleviated as of v12, but it's still not going to be something you really want to do if you have an alternative. I'd try replacing the use of information_schema.columns with something like (pg_class c join pg_attribute a on c.oid = a.attrelid and a.attnum > 0 and not a.attisdropped) (Hm, I guess you also need to join to pg_namespace to get the schema name.) You could simplify the join condition with psut to be c.oid = psut.relid, though you're still stuck with doing schemaname+tablename comparison to join to pg_stats. regards, tom lane