Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQpj2-0017Ys-Tp for pgsql-admin@arkaria.postgresql.org; Tue, 01 Aug 2023 13:47:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qQpj1-006fLi-1I for pgsql-admin@arkaria.postgresql.org; Tue, 01 Aug 2023 13:47:48 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQpj0-006fLa-Mf for pgsql-admin@lists.postgresql.org; Tue, 01 Aug 2023 13:47:48 +0000 Received: from mail-oa1-x2f.google.com ([2001:4860:4864:20::2f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qQpiz-000Csh-Nj for pgsql-admin@lists.postgresql.org; Tue, 01 Aug 2023 13:47:47 +0000 Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-1bb575a6ed3so4463460fac.2 for ; Tue, 01 Aug 2023 06:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690897664; x=1691502464; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=YCTgs9c6hRUBVqqNMgijQmqbXgKz7hmrgHVeo8MOkps=; b=D1c099352zbKjnU/Rq2dYTET9uQBOPpp9Zun9HDFlgREd/XloJ1PA8MV9C3YgeTl/1 wOEy/TDM3dkYJnzovJm11m2zaolbQrhOEg3sGwE2kPLQRY/5hNcDWyYP4pttHUKuN7/a uJi//EziqIWZZGhJ3uMBHkBhh51W5YLPFcfSWKN3jA/sj3Y+bHzC4XlAFlTDxZdoph6B h1deiIrYiYxl6gU/SxwZgmYUsfOtv0cWzbBKK8TdcyZggJDNDJ9CJxQyCAo1jhdn5DKL fHS3ziZ7/Fftz+eYRnlBL6ZotyjZaZ3Jhm2m9iM+HbCvf+BDWZ+l8aQIz9ulz4u4R5mN m9Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690897664; x=1691502464; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=YCTgs9c6hRUBVqqNMgijQmqbXgKz7hmrgHVeo8MOkps=; b=el9WrEHsFKaimvtdK6Z6BD0DNeRJY9kdlWcCblmf5o+TrHib1SZaOKE5CX2+mvHr9H zZ3qEI8yYVHHrpflDsmyaRnFG8Mfi6Ozh+gGLeSB63MwC752ZmlcmD4sXADxsaC69Njo ApGtHppLjGmxLTlPgRd3egkgqLlPrQpHAsdcqm3pvlCgNq6+MLqQhBdQvSnfWI+TR/vj mNp9Int7DNh/xD9JlVHTmA3eKKTExX17tN8QJdbm9+5SNgry4TpukFvvpn/hqR0yBA0W v1xO7imI8+NrA9YYU8WvHBzFTPTDaSbjHzr9/uAZP/Cot4chOv5Th6e1RcdZUbS7Y8ab u9FA== X-Gm-Message-State: ABy/qLbvufJwYEfRhjeBPrDViR9xKjPGHLh1Pb61PNvDIBN4OYHhncvP UitSu+O+bg3j+3ibOT1OCOMexzExhMnX2K9JJ4Vt70xbsHY= X-Google-Smtp-Source: APBJJlF7W+vCTAgu4K8uWtEonS5jmuwhXQwhhdkMuIhSQT76shqNQT8yGMVqf4KZS9BbpeLEcx5BNtrXog/4Relg4FU= X-Received: by 2002:a05:6870:169c:b0:1b7:27f7:da8d with SMTP id j28-20020a056870169c00b001b727f7da8dmr15337703oae.38.1690897664287; Tue, 01 Aug 2023 06:47:44 -0700 (PDT) MIME-Version: 1.0 From: richard coleman Date: Tue, 1 Aug 2023 09:47:33 -0400 Message-ID: Subject: analyze foreign tables To: Pgsql-admin Content-Type: multipart/alternative; boundary="000000000000a1a8040601dcca8d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a1a8040601dcca8d Content-Type: text/plain; charset="UTF-8" Hello all, In PostgreSQL foreign tables are not automatically analyzed and analyze must be specifically called on each table. In the case of sharing tables between PostgreSQL clusters, there is the use_remote_estimate foreign server option. In some of our multi terabyte databases, manually running analyze on all of the foreign tables can take more than a day. This is per database containing the foreign schema. Since we have certain large schema that we have centrally located and share to all of our other database clusters, this really adds up. use_remote_estimate isn't really a solution as it adds way too much overhead and processing time to every query run. Since these tables are being continuously analyzed in the database that hosts the data, is there some way that they statistics could be easily passed through the foreign server mechanism to the remote database that's calling the query? Unless I'm missing something we can either: 1. manually run analyze on each foreign table in each database that points to the host table 2. set use_remote_estimate = true which will cause PostgreSQL to re-obtain statistics on a per query basis. What I am hoping for is either: 1. pass through the results of analyze from the source database to the one where the foreign query is being run 2. add the ability to automatically run analyze on foreign tables just as they are currently run on local tables. Of the two, #1 would seem to be the easiest and least wasteful of resources. Thanks, rik. --000000000000a1a8040601dcca8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,=C2=A0

In PostgreSQL foreign tables= are not automatically analyzed and analyze must be specifically called on = each table.=C2=A0 In the case of sharing tables between PostgreSQL clusters= , there is the=C2=A0use_remote_estimate foreign server option.
<= div>
In some of our multi terabyte databases, manually runnin= g analyze on all of the foreign tables can take more than a day.=C2=A0 This= is per database containing the foreign schema.=C2=A0 Since we have certain= large schema that we have centrally located and share to all of our other = database clusters, this really adds up.

use_remote= _estimate isn't really a solution as it adds way too much overhead and = processing time to every query run.

Since thes= e tables are being continuously analyzed in the database that hosts the dat= a, is there some way that they statistics could be easily passed through th= e foreign server mechanism to the remote database that's calling the qu= ery?

Unless I'm missing something we can eithe= r:
1. manually run analyze on each foreign table in each database that p= oints to the host table
2. set use_remote_estimate =3D true which= will cause PostgreSQL to re-obtain statistics on a per query basis.
<= div>
What I am hoping for is either:
1. pass throug= h the results of analyze from the source database to the one where the fore= ign query is being run
2. add the ability to automatically run an= alyze on foreign tables just as they are currently run on local tables.

Of the two, #1 would seem to be the easiest and least= wasteful of resources.

Thanks,=C2=A0
ri= k.


--000000000000a1a8040601dcca8d--