Date: Wed, 2 Apr 2025 21:38:18 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Robert Treat <rob@xzilla.net>,
	Robert Haas <robertmhaas@gmail.com>,
	Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Michael Paquier <michael@paquier.xyz>,
	jian he <jian.universality@gmail.com>,
	Bruce Momjian <bruce@momjian.us>,
	Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Magnus Hagander <magnus@hagander.net>,
	Stephen Frost <sfrost@snowman.net>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	Peter Smith <smithpb2250@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	alvherre@alvh.no-ip.org
Subject: Re: Statistics Import and Export
Message-ID: <Z-30mug1X82YOn-0@nathan>
References: 
 <CADkLM=desCuf3dVHasADvdUVRmb-5gO0mhMO5u9nzgv6i7U86Q@mail.gmail.com>
 <f248676c32cbb3a4dd0da13bc84af43760239bf2.camel@j-davis.com>
 <CADkLM=dG+8jW4UAwP69o7Q92FOXpoN8Pb9kD_Fck1_BBn+gwgQ@mail.gmail.com>
 <CADkLM=domd5+CvjKMHGbOfvSuY6J8G-x+9M2D6Ss2HamYefE9w@mail.gmail.com>
 <Z-tQa5zsVkcCyYin@nathan>
 <Z-wubg4vnItKnOCj@nathan>
 <Z-wz_sZdceGJ-fuI@nathan>
 <88af35fe0ff24cc4e0700b841aa60a0865f11648.camel@j-davis.com>
 <Z-ytSGUZAQNIM9GJ@nathan>
 <CADkLM=d4U6hjoLGx2tRxLzSsEDYz7oj8PmmTYPKmnfPk5RLzKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CADkLM=d4U6hjoLGx2tRxLzSsEDYz7oj8PmmTYPKmnfPk5RLzKQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/Z-30mug1X82YOn-0%40nathan>
Precedence: bulk

On Wed, Apr 02, 2025 at 10:34:58PM -0400, Corey Huinker wrote:
>>
>> > Also, why do we need the clause "WHERE s.tablename = ANY($2)"? Isn't
>> > that already implied by "JOIN unnest($1, $2) ... s.tablename =
>> > u.tablename"?
>>
>> Good question.  Corey, do you recall why this was needed?
>>
> 
> In my patch, that SQL statement came with the comment:
> 
> + /*
> + * The results must be in the order of relations supplied in the
> + * parameters to ensure that they are in sync with a walk of the TOC.
> + *
> + * The redundant (and incomplete) filter clause on s.tablename = ANY(...)
> + * is a way to lead the query into using the index
> + * pg_class_relname_nsp_index which in turn allows the planner to avoid an
> + * expensive full scan of pg_stats.
> + *
> + * We may need to adjust this query for versions that are not so easily
> + * led.
> + */

Thanks.  I included that in the latest patch set.

-- 
nathan