Date: Wed, 12 Jun 2024 07:47:43 +0000 (UTC)
From: Chandy G <vgchandru@yahoo.com>
To: "pgsql-general@postgresql.org" <pgsql-general@postgresql.org>
Message-ID: <1204595253.3110982.1718178463166@mail.yahoo.com>
Subject: postgres table statistics
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_3110981_559059046.1718178463165"
References: <1204595253.3110982.1718178463166.ref@mail.yahoo.com>
Content-Length: 3596
Archived-At: <https://www.postgresql.org/message-id/1204595253.3110982.1718178463166%40mail.yahoo.com>
Precedence: bulk

------=_Part_3110981_559059046.1718178463165
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,=20
=C2=A0 We have postgres 13.9 running with tables thats got billions of reco=
rds of varying sizes. Eventhough pg jdbc driver=C2=A0 provides a way to set=
 fetch size to tune the driver to achieve better throughput, the JVM fails =
at the driver level when records of large size (say 200mb each) flows throu=
gh.=C2=A0 this forces to reduce the fetch size (if were to operate at a fix=
ed Xmx setting of client jvm).
It get a bit trickier when 100s of such tables exists with varying records =
sizes. trying to see if the fetch size can be set dynamically based on the =
row count and the record size distribution for a table. Unfortunately, tryi=
ng to get this data by a query run against each table (for row size: max(le=
ngth(t::text))) seem to be=C2=A0 quite time consuming too.
Does postgres maintain metadata about tables for the following.1. row count=
=20
2. max row size.=20

or is there some other pg metadata that can help get this data quicker.
TIA.


------=_Part_3110981_559059046.1718178463165
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head></head><body><div class=3D"yahoo-style-wrap" style=3D"font-fami=
ly:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div dir=
=3D"ltr" data-setdir=3D"false">Hi, <br></div><div dir=3D"ltr" data-setdir=
=3D"false">&nbsp; We have postgres 13.9 running with tables thats got billi=
ons of records of varying sizes. Eventhough pg jdbc driver&nbsp; provides a=
 way to set fetch size to tune the driver to achieve better throughput, the=
 JVM fails at the driver level when records of large size (say 200mb each) =
flows through.&nbsp; this forces to reduce the fetch size (if were to opera=
te at a fixed Xmx setting of client jvm).</div><div dir=3D"ltr" data-setdir=
=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false">It get a bit tr=
ickier when 100s of such tables exists with varying records sizes. trying t=
o see if the fetch size can be set dynamically based on the row count and t=
he record size distribution for a table. Unfortunately, trying to get this =
data by a query run against each table (for row size: <span><span style=3D"=
color: rgb(29, 28, 29); font-family: Monaco, Menlo, Consolas, &quot;Courier=
 New&quot;, monospace; font-size: 12px; font-style: normal; font-weight: 40=
0; letter-spacing: normal; text-align: left; text-indent: 0px; text-transfo=
rm: none; word-spacing: 0px; text-decoration-thickness: initial; text-decor=
ation-style: initial; text-decoration-color: initial; display: inline !impo=
rtant; float: none;">max(length(t::text))</span></span>) seem to be&nbsp; q=
uite time consuming too.</div><div dir=3D"ltr" data-setdir=3D"false"><br></=
div><div dir=3D"ltr" data-setdir=3D"false">Does postgres maintain metadata =
about tables for the following.</div><div dir=3D"ltr" data-setdir=3D"false"=
>1. row count <br></div><div dir=3D"ltr" data-setdir=3D"false">2. max row s=
ize. <br></div><div dir=3D"ltr" data-setdir=3D"false"><br></div><div dir=3D=
"ltr" data-setdir=3D"false">or is there some other pg metadata that can hel=
p get this data quicker.</div><div dir=3D"ltr" data-setdir=3D"false"><br></=
div><div dir=3D"ltr" data-setdir=3D"false">TIA.</div><div dir=3D"ltr" data-=
setdir=3D"false"><br></div><div dir=3D"ltr" data-setdir=3D"false"><br></div=
><div dir=3D"ltr" data-setdir=3D"false"><br></div><div><br></div></div></bo=
dy></html>
------=_Part_3110981_559059046.1718178463165--