Re: Further cleanup related to statistics import support in postgres_fdw

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Subject: Re: Further cleanup related to statistics import support in postgres_fdw
Date: 2026-09-04 11:34:26
Message-ID: CAHGQGwHq1VuXwxeDU8N4dd9U4RFEW982qQ9C26mRQDs3nu_Naw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 4, 2026 at 6:51 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
>
> On Thu, Sep 3, 2026 at 7:45 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote:
> > Here is a new version of the patch, in which I fixed indentation after
> > tweaking comments/docs a little bit for clarity/readability. I will
> > push/backpatch this version if no objections.
>
> Done.

After the patch was committed, I observed that stats import could fail with
the following warning even though the remote table is no longer
inherited. Is this behavior intentional?

WARNING: could not import statistics for foreign table
"public.ft" --- remote table "public.t" is inherited

Here is the procedure to reproduce this situation. The point is that
the inheritance table is created and then dropped:

--------------------------------
CREATE TABLE t AS SELECT i FROM generate_series(1, 100) i;
ANALYZE t;
CREATE TABLE tt () INHERITS (t);
DROP TABLE tt;

CREATE EXTENSION postgres_fdw;
CREATE SERVER loopback FOREIGN DATA WRAPPER postgres_fdw;
CREATE USER MAPPING FOR public SERVER loopback;
CREATE FOREIGN TABLE ft (i int) SERVER loopback OPTIONS (table_name
't', import_stats 'true');

ANALYZE VERBOSE ft;
WARNING: could not import statistics for foreign table "public.ft"
--- remote table "public.t" is inherited
--------------------------------

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2026-09-04 11:36:49 Re: PG19 FK fast path: OOB write and missed FK checks during batched
Previous Message Fujii Masao 2026-09-04 10:41:10 Re: pg_createsubscriber does not check output_plugin_libraries