From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alexander Korotkov <aekorotkov@gmail.com>
cc: Justin Pryzby <pryzby@telsasoft.com>,
        Nathan Bossart <nathandbossart@gmail.com>,
        Michael Banck <mbanck@gmx.net>,
        Laurenz Albe <laurenz.albe@cybertec.at>,
        vignesh C <vignesh21@gmail.com>,
        "Kumar,
    Sachin" <ssetiya@amazon.com>,
        Robins Tharakan <tharakan@gmail.com>, Jan Wieck <jan@wi3ck.info>,
        Bruce Momjian <bruce@momjian.us>, Andrew Dunstan <andrew@dunslane.net>,
        Magnus Hagander <magnus@hagander.net>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        pgsql-hackers@postgresql.org
Subject: Re: pg_upgrade failing for 200+ million Large Objects
In-reply-to: <CAPpHfdu63MK5k4qBNc4YV14MFdNq8rCsvz0x7+Z=ijbFm1y6wQ@mail.gmail.com>
References: <!2751089.1710544721@sss.pgh.pa.us> <4a3ebf7d81bfc6dd4d545e5b27d6e8f6c32d8937.camel@cybertec.at> <3023817.1710629175@sss.pgh.pa.us> <6603e4e0.500a0220.a557f.4f39@mx.google.com> <3304322.1711551245@sss.pgh.pa.us> <20240327150826.GB3994937@nathanxps13> <20240401191930.GA2302032@nathanxps13> <1217588.1711999706@sss.pgh.pa.us> <ZqEND4ZcTDBmcv31@pryzbyj2023> <CAPpHfduUSA7c0YrTxN443SwXXCL41vmXkavYJjN8GS3Wc5Z42w@mail.gmail.com> <ZqQIxIsaPWO6coil@pryzbyj2023> <1870579.1722033430@sss.pgh.pa.us> <CAPpHfdtpr2FYVYqmARZdSp=2zsndgJgmSsHFxFFNTiYRfX8uaA@mail.gmail.com> <1873872.1722035181@sss.pgh.pa.us> <CAPpHfdu63MK5k4qBNc4YV14MFdNq8rCsvz0x7+Z=ijbFm1y6wQ@mail.gmail.com>
Comments: In-reply-to Alexander Korotkov <aekorotkov@gmail.com>
	message dated "Sat, 27 Jul 2024 06:00:47 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1903478.1722049686.1@sss.pgh.pa.us>
Date: Fri, 26 Jul 2024 23:08:06 -0400
Message-ID: <1903479.1722049686@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/1903479.1722049686%40sss.pgh.pa.us>
Precedence: bulk

Alexander Korotkov <aekorotkov@gmail.com> writes:
> J4F, I have an idea to count number of ';' sings and use it for
> transaction size counter, since it is as upper bound estimate of
> number of SQL commands :-)

Hmm ... that's not a completely silly idea.  Let's keep it in
the back pocket in case we can't easily reduce the number of
SQL commands in some cases.

It's late here, and I've got some other commitments tomorrow,
but I'll try to produce a patch to merge more of the SQL
commands in a day or two.

			regards, tom lane