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 1hy12c-0006aG-LH for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2019 21:42:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hy12b-00018t-CD for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Aug 2019 21:42:45 +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 1hy12b-00018m-3C for pgsql-hackers@lists.postgresql.org; Wed, 14 Aug 2019 21:42:45 +0000 Received: from mail-qt1-x841.google.com ([2607:f8b0:4864:20::841]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hy12X-0007qy-8r for pgsql-hackers@lists.postgresql.org; Wed, 14 Aug 2019 21:42:44 +0000 Received: by mail-qt1-x841.google.com with SMTP id e8so272610qtp.7 for ; Wed, 14 Aug 2019 14:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=eFVwz0P0Yup6m2fCRHSmLgbefzM++ZXCse8kXLiYrx0=; b=hafGml6ihTH5iah1SnoMNFGO3scWBlsKceOiJvPpUZJPbI2BMj7Gn3AQPQ6v9bofvM 2gmb3iN4/G6xCYxxJMqyxAYPDRmV1ruVr0+jgUeMa6HQUM7fLJMdTKqaKXYb1PeNIg0O +n8D7U90vBKD+dI+VIR3wONP/IZGxmcCPhGW8IuIp50Os5/JRqp8VzCRCtfjofnpgR9q SYN6kDGLLxITsJ6iFYHmfbvwDMbycentQiztZm5WKNdOjh2QrxUnb2eP12vw7utasXbt svewAcBNcHj+aFEBmmVj8cPi9BjpK4U+ZFiWW6+/ubDtaNMtta/PPR+Pe8k01RAZvDHh PBPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=eFVwz0P0Yup6m2fCRHSmLgbefzM++ZXCse8kXLiYrx0=; b=C8VYSJ6vUDyAzmDZzfp6ANxqluEv1r/KI46F7HgTMudJIrsoY9PvLTB82Fb+kz5xDw ZjQNxDqv2QxIAbvxDSXz80O6lQ42IZRezfoK+BV7827Z0MgriADNJyU8Dkt1dmx3NSwz uPaFNgcU6cHbkZq5zClqfLshgyDdyQSkVINLQKImQg115Lv3SCQaq10eW2tX2EnnYQbM z730ZxGocLMrGX2kElFEglxrgguleeWoVMByoDnjab6SCkYckNehXVDuIB9B+2uFf5hC EzoJ7McIrPWtggJppLe+EXPTDErK2dKu0N0XtcDGg1TqlEt5Y0rR9ojsr5H9uClsv5IC slmA== X-Gm-Message-State: APjAAAUJipQRKGxyl3F7Cv5znaPmd22RI1YQnSHdt6Ung63lTaC15Yx1 WpW1xfvFTbafL/jv/x+voCzc1w== X-Google-Smtp-Source: APXvYqxKl2+N5b6+JRHv1EpwNHDygYC0Z2WQULYK+t0Bg6VChJwjJQDp+oLqVH9jKLn1X1ayVXh2qw== X-Received: by 2002:a0c:fa89:: with SMTP id o9mr1191101qvn.165.1565818958759; Wed, 14 Aug 2019 14:42:38 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id n21sm570930qtc.70.2019.08.14.14.42.37 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 14 Aug 2019 14:42:38 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 7767012116B; Wed, 14 Aug 2019 17:42:36 -0400 (-04) Date: Wed, 14 Aug 2019 17:42:36 -0400 From: Alvaro Herrera To: Etsuro Fujita Cc: Tatsuro Yamada , Pg Hackers Subject: Re: progress report for ANALYZE Message-ID: <20190814214236.GA12940@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Aug-14, Etsuro Fujita wrote: > On Tue, Aug 13, 2019 at 11:01 PM Alvaro Herrera > wrote: > > On the subject of FDW support: I did look into supporting that before > > submitting this. I think it's not academically difficult: just have the > > FDW's acquire_sample_rows callback invoke the update_param functions > > once in a while. Sadly, in practical terms it looks like postgres_fdw > > is quite stupid about ANALYZE (it scans the whole table??) so doing > > something that's actually useful may not be so easy. At least, we know > > the total relation size and maybe we can add the ctid column to the > > cursor in postgresAcquireSampleRowsFunc so that we have a current block > > number to report (becing careful about synchronized seqscans). > > I don't follow this thread fully, so I might miss something, but I > don't think that's fully applicable, because foreign tables managed by > postgres_fdw can be eg, views on the remote side. Oh, hmm, well I guess that covers the tables and matviews then ... I'm not sure there's a good way to cover foreign tables that are views or other stuff. Maybe that'll have to do. But at least it covers more cases than none. > > I do wonder why doesn't postgres_fdw use TABLESAMPLE. > > Yeah, that's really what I'm thinking for PG13; but I think we would > still need to scan the whole table in some cases (eg, when the foreign > table is a view on the remote side), because the TABLESAMLE clause can > only be applied to regular tables and materialized views. Sure. > > I did not look at other FDWs at all, mind. > > IIUC, oracle_fdw already uses the SAMPLE BLOCK clause for that. Right? Yeah, it does that, I checked precisely oracle_fdw this morning. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services