From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: Corey Huinker <corey.huinker@gmail.com>,
        Andres Freund <andres@anarazel.de>,
        Michael Paquier <michael@paquier.xyz>,
        jian he <jian.universality@gmail.com>,
        Nathan Bossart <nathandbossart@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
In-reply-to: <bbdf2c731b5eda5deed427b2821e09109919595c.camel@j-davis.com>
References: <sdno5atrplq5b67vcx7x6fkzevwkzojd23izbguy2yma424wmp@siwbi3ijxdxs> <x5yo5ly5u3dhzfaq3hrzeqhju3io5zmwk4yqrkge3ywcflffck@ghbbgsfv56yb> <3670503.1740173078@sss.pgh.pa.us> <blezfpeafycxlizyynwvwzh2vywmklhvfqudhicjrccu4raqpx@4ttfufowc2vo> <3728741.1740178078@sss.pgh.pa.us> <CADkLM=f0a43aTd88xW4xCFayEF25g-7hTrHX_WhV40HyocsUGg@mail.gmail.com> <97b451228227c555be1a4f79c4a62ddec9a74f06.camel@j-davis.com> <CADkLM=ckXu5wzSQZ3Y_fvAaL8rZ+upZdSecBLf5FCTMj7M6T-A@mail.gmail.com> <b227c4fca29dfb893bb414ce6d84fc2377489ecc.camel@j-davis.com> <CADkLM=dRMC6t8gp9GVf6y6E_r5EChQjMAAh_vPyih_zMiq0zvA@mail.gmail.com> <y2d36zf6pl3n6ni6e4ctblu3a5iazi2dycknq53h2mjvp7lto4@hhww3h2qgdrw> <CADkLM=d3H8xghP8QmOL6f_mBgP_X23-=2hOnYx7mqYiNSHimiQ@mail.gmail.com> <bbdf2c731b5eda5deed427b2821e09109919595c.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Mon, 24 Feb 2025 11:45:51 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1471692.1740427438.1@sss.pgh.pa.us>
Date: Mon, 24 Feb 2025 15:03:58 -0500
Message-ID: <1471693.1740427438@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1471693.1740427438%40sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> But you have a point in that float4in() does slightly more work than
> strtof() to handle platform differences about NaN/Inf. I'm not sure how
> much to weigh that concern, but I agree that there is non-zero
> cognitive overhead here.

If we're speaking strictly about the reltuples value, I'm not hugely
concerned about that.  reltuples should never be NaN or Inf.  There
is a nonzero chance that it will round off to a fractionally
different value if we pass it through strtof/sprintf on the pg_dump
side, but nobody is really going to care about that.  (Maybe our
own pg_dump test script would, thanks to its not-too-bright dump
comparison logic.  But that script is never going to see reltuples
values that are big enough to be inexact in a float4.)

I do buy the better-preserve-it-exactly argument for other sorts
of statistics, where we don't have such a good sense of what might
matter.

			regards, tom lane