Date: Mon, 18 Jan 2016 16:50:09 +0100 (CET)
From: Andreas Joseph Krogh <andreas@visena.com>
To: pgsql-sql@postgresql.org
Message-ID: <VisenaEmail.ca.3430189fb000a7e8.152556785e6@tc7-visena>
In-Reply-To: <1592189786.7265044.1453131627096.JavaMail.yahoo@mail.yahoo.com>
Subject: Re: BYTEA
MIME-Version: 1.0
Content-Type: multipart/related;
 boundary="----=_Part_886_471554581.1453132209697"
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

------=_Part_885_1153665805.1453132209697
Content-Type: multipart/related; 
	boundary="----=_Part_886_471554581.1453132209697"

------=_Part_886_471554581.1453132209697
Content-Type: multipart/alternative;
 boundary="----=_Part_887_2066267877.1453132209712"

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

P=C3=A5 mandag 18. januar 2016 kl. 16:40:26, skrev Eugene Yin <eugeneymail@=
ymail.com=20
<mailto:eugeneymail@ymail.com>>:
"if you only work with small-ish binary data, yes - BYTEA does the job."
=C2=A0
--The goal is to save/retrieve the user's photos (JPEG, TIFF, GIF) and PDF=
=20
files.=C2=A0 The size of each file is less than
5 MB.=C2=A0 For such purpose, is BYTEA ok?=C2=A0 If not, then how about 1 M=
B each?

=C2=A0

Again, that depends. If you plan on having 1000 simultaneous users then hav=
ing=20
everything in memory might not be a good idea. Remember the memory consumed=
 by=20
the JVM is quite a lot more the the raw byte-size of each image/blob.
=C2=A0
"whole byte-array is kept in memory, both in the JAVA-app and in PG" =C2=A0
--I believe in Java the GarbageCollector will clean it up (?).=C2=A0 "Who" =
will=20
then clean up the Pg side?

=C2=A0
It will clean it up, if it's not referenced anymore. PG will clean up its s=
ide=20
at the end of the transaction (at least).
=C2=A0
=C2=A0
"whole byte-array is kept in memory, both in the JAVA-app and in PG" =C2=A0
--Does that mean for the OID, byte-array is NOT kept in memory (of JAVA-app=
 or=20
PG)?=C2=A0 If so, where is it kept? And how they are got cleaned up?

=C2=A0
As reading BLOBs (using the OID-type) really means your processing a stream=
 of=20
bytes it's really up to you to decide the size of the byte-buffer you want =
to=20
use. Only this byte-buffer is kept in memory (and is freed by the GC when n=
ot=20
referenced anymore), which often is much less than the whole BLOB.

=C2=A0
-- Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
andreas@visena.com <mailto:andreas@visena.com>
www.visena.com <https://www.visena.com>
 <https://www.visena.com>


=C2=A0

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

<div>
<div>P=C3=A5 mandag 18. januar 2016 kl. 16:40:26, skrev Eugene Yin &lt;<a h=
ref=3D"mailto:eugeneymail@ymail.com">eugeneymail@ymail.com</a>&gt;:</div>

<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=3D"color:#000; background-color:#fff; font-family:HelveticaNeue,=
 Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px=
">
<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3289"><b><span id=3D"yui_=
3_16_0_1_1453087055678_3408">&quot;</span>if you only work with small-ish b=
inary data, yes - BYTEA does the job.&quot;</b></div>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3539">=C2=A0</div>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3574">--The goal is to sa=
ve/retrieve the user's photos (JPEG, TIFF, GIF) and PDF files.=C2=A0 The si=
ze of each file is less than</div>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_4004">5 MB.=C2=A0 For suc=
h purpose, is BYTEA ok?=C2=A0 If not, then how about 1 MB each?</div>
</div>
</blockquote>

<div>=C2=A0</div>
</div>

<div>Again, that depends. If you plan on having 1000 simultaneous users the=
n having everything in memory might not be a good idea. Remember the memory=
 consumed by the JVM is quite a lot more the the raw byte-size of each imag=
e/blob.</div>

<div>=C2=A0</div>

<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=3D"color:#000; background-color:#fff; font-family:HelveticaNeue,=
 Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px=
"><b>&quot;whole byte-array is kept in memory, both in the JAVA-app <em id=
=3D"yui_3_16_0_1_1453087055678_2672">and</em> in PG&quot;</b>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3924">=C2=A0</div>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3773">--I believe in Java=
 the GarbageCollector will clean it up (?).=C2=A0 &quot;Who&quot; will then=
 clean up the Pg side?</div>
</div>
</blockquote>

<div>=C2=A0</div>

<div>It will clean it up, if it's not referenced anymore. PG will clean up =
its side at the end of the transaction (at least).</div>

<div>=C2=A0</div>

<div>
<div>=C2=A0</div>

<blockquote style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt=
 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style=3D"color:#000; background-color:#fff; font-family:HelveticaNeue,=
 Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:13px=
"><b>&quot;whole byte-array is kept in memory, both in the JAVA-app <em id=
=3D"yui_3_16_0_1_1453087055678_2672">and</em> in PG&quot;</b>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3879">=C2=A0</div>

<div dir=3D"ltr" id=3D"yui_3_16_0_1_1453087055678_3926">--Does that mean fo=
r the <b>OID,</b> byte-array is NOT kept in memory (of JAVA-app or PG)?=C2=
=A0 If so, where is it kept? And how they are got cleaned up?</div>
</div>
</blockquote>

<div>=C2=A0</div>

<div>As reading BLOBs (using the OID-type) really means your processing a s=
tream of bytes it's really up to you to decide the size of the byte-buffer =
you want to use. Only this byte-buffer is kept in memory (and is freed by t=
he GC when not referenced anymore), which often is much less than the whole=
 BLOB.</div>
</div>

<div>=C2=A0</div>

<div class=3D"origo-email-signature">
<div>--
<div><span style=3D"font-family:arial,helvetica,sans-serif;"><strong>Andrea=
s Joseph Krogh</strong></span></div>

<div><span style=3D"font-family:arial,helvetica,sans-serif;">CTO / Partner<=
/span> - Visena AS</div>

<div><span style=3D"font-family:arial,helvetica,sans-serif;">Mobile: +47 90=
9 56 963</span></div>

<div><a href=3D"mailto:andreas@visena.com">andreas@visena.com</a></div>

<div><a href=3D"https://www.visena.com">www.visena.com</a></div>

<div style=3D"padding-top: 5px"><a href=3D"https://www.visena.com"><img alt=
=3D"" src=3D"cid:part_F1521643311479SX2JJ"></a></div>
</div>
</div>

<div>=C2=A0</div>
------=_Part_887_2066267877.1453132209712--

------=_Part_886_471554581.1453132209697
Content-Type: image/png
Content-Transfer-Encoding: base64
Content-Disposition: inline
Content-ID: <part_F1521643311479SX2JJ>

iVBORw0KGgoAAAANSUhEUgAAAIUAAAAYCAYAAADUIj6hAAAABHNCSVQICAgIfAhkiAAABzBJREFU
aEPtmNFxHDcMhmVP3i1VECpvnjzkVIHWFfhcgVcVRKrAUgWRK/C6Al8H3lTgy0PGbzFdQc4VJP/H
ADs43q6kROeJNbOYgQACIAgCWJKng4MZ5gxUGXh0U0b+SIuF9G+EWXj2Q15vbrE/NPtk9uub7Gfd
t5mBx1NhqSEo8HshjbEUtlO2yIM9tsx5dZP9rPt2MzDZFAqZE4LGcFjdsg3saQaHt7fY70X949On
aS+OZidDBkavD33157L4xaw2os+Mp/DAC10l2XhOCeStj0W5ajrJL8WfCi80Xgf9vVlrhg9yRONe
/f7xI2vNsIcM7JwU9o6oGyJrLT8JOA1aX9sKP4wl94bAniukEbo/n7YPmuTETzIab4Y9ZWCrKexd
8M58lxPCvvD6aihfvexbEQoPYO8NQRO0JnddGO6FJYaVsBde7cXj7KRk4LsqDxQzCYeGsJNgaXZe
+JXkyGgWINq3Gp+bHNILz+wEYs5qH1eJrouNrpDXtk4O6x1IvtD40GWyJYYdkF0jIbYZlN16xygI
gl9smbMDsmFdfAKb23xGB8H/mv3tOJfArs1kukk79DEPdQ5u0g1vCvvqKXIW8mZYW+F3Tg4r8HvZ
kQCCLydK8EFMQCe5N8RgL9mRG0SqQFuNvdE6beSs0qPDBuCdg0+gvClso8SbTO4ki7mQzQqBrcMH
QPwReg2wW8umEe/+L8T/LEzBGF9nXjzZ46s+ITHvhegW8LL39xm6App7KYL/GE+vcYnFbJiP/0aY
hdiCnRC7jaj7eiK2ETInC5PRF6LYkSN0+HabF75WuT6syCyI0YkVGGMvUC33AmfZTDUEj8u6IVhu
EhRUJ2U2g6UlugyNb03Hl9obHwlxJbcRzcYjO4QPjVfGFTQav4vrmp7cpMp2qbHnBxWJbisbho2Q
XI6C1sIHDUFhH4Hij4UbIev66eANeiwbkA+LBsO36zAHzoXU7AhbqLAXEiOYTXcSdO8VS9L4wN8U
BIYhBd6oSUgYMijOkecRuTdQa/YiBXhbXFcnCnI2SrfeBG9NydrLYMhGHa5qB9pQIxlzAE6Okjzx
JO5afGe6kmhBicWKQNKuTZ5EW+MjQY8v/9rQ0bhJSJyNGUe/JH1t8h1iMbdSPAvxHYin6YmN9YBX
QmTYZZNh14vHhhhal5vtcIrJjmvszPRJdExH3MWHvykoBEc9CoCGWJisOLOGoCORs1FvIMbYA8z3
kwM59oemy6LlWrLxFLmWgiQAfEGd8S+NssbK+EhyGLxUkhhiy717waBqHOJYSEacwBejkFNhjJNj
v/gANOdQxPfciP/JVBCK2cOIcg3RRJ+CPrLPNVhhN6F38VKMF3XLlIJrjU5C8gMFxvKDvOcPc4rV
NjCn7KM0BV+161V8viSCuJZ8SITGJGEh7IUUlxOFMYUH1kJOCN4Wh+I5pqCuK01k40kSNtnKiKIl
UfxAgW5sU5JlS05rtt5YFJF1SWoqHv6BRgQcA4/bdb9WRjmMk3jyUMAbIoyJq9e4cVmgzKt9j5gN
J/aYDhk+hhjExwaPcz5PObA5Zd9bvz5UzCTZuZDidu5AchpiKSwPR+TV1bCWqBQ9nCjJ5neivC82
Nr4LeS2j1gw5LUqwBuhGQQU5UwHeSslXkwIynz2U2A2yKDgG7OffwLA3TpGRpk0Tzpj3ZEJXi/GR
a6GN0e0NtppChePdcAz1FTS+FN8Kpxoiykk+J8fC5tenjbu9kSqpHLu9jBrhUuhNwVGbpyZrzrl0
HPVD8SXj5EOOD/eDC64VjvYBZLuUbIVAfBN1t/C/SU+cAGtdGo+fVnzycUX5wmn6eCKPmWYJG2E/
ppTsuRCbvUD9fwquksG5GqLVKhzDQ3GrEyLKSXhsiK3T5j9EyxffCFOYi2wUlPyFFDQAhehESDjQ
GoX0ho0oj8RPou6TxHJdcT0NTcWkO0AnG7+uXsnHqcas/72wvWF+mSf7N/Watp9kTXoluzeS0fB9
9CcZ/hvhSZTfh99pispZOXL9KrGrARkNUMu9ITbScZWs7xOYNt9pwxSZtYDsX/GE3xTkrXgwAsXm
fud08FiTeC+m2/o7ppo+PTS/NBK5ARpDG5YHr++DpmVfreYdiX8mnp+DzPEG9WbqJON0JBenZofs
sxBA1gj5NXGvfJu/Qh7HwQh/VDUEyUxCit5hH94QfKkEdu+GwK8BX0hvCF+D67xhjmXQCXMwJCZ+
olK0A1EKRCE4snsh42w8Mv/Zhxw9iD7Cjo7CyQC/KyF6oBfShL4PYgG+CHsYKyZxvxZSZBAgjhIz
YDz+AbfD37GtbaoSKzgGt+lKfI/GZtay6vG4VXTpPsh+IcQhOk9I7WYeP5AM3HZ9+DaSGIp9HIuu
huC4pCGGx+YD2fcc5tfIAA0h/Et4/jX8zz4fWAasIf4UbR9Y6HO4d8jAnd4U0Y8ageuCB+c+H5R3
CHU2mTMwZ+B/y8DfSMBLLOYXVuEAAAAASUVORK5CYII=
------=_Part_886_471554581.1453132209697--

------=_Part_885_1153665805.1453132209697--