Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aLCh7-0008OJ-2J for pgsql-sql@arkaria.postgresql.org; Mon, 18 Jan 2016 16:30:17 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aLCh6-0001Vz-K6 for pgsql-sql@arkaria.postgresql.org; Mon, 18 Jan 2016 16:30:16 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aLCh6-0001Vh-6n for pgsql-sql@postgresql.org; Mon, 18 Jan 2016 16:30:16 +0000 Received: from nm50-vm8.bullet.mail.bf1.yahoo.com ([216.109.115.239]) by magus.postgresql.org with esmtps (TLS1.0:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aLCh1-00043s-Sx for pgsql-sql@postgresql.org; Mon, 18 Jan 2016 16:30:15 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ymail.com; s=s2048; t=1453134609; bh=Vl4cgTL0MwFw6nOnXEurvrPH90zEIzksTk7ebqB17Sw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=oPUUxWXwHcodBJ1N86j1hyx846gLY5C8aWOzgRfAT88BeE83BXgPI774Yg9H25X0HKJG8QiC6IeF3G8WdA6sC6zsfDoblgYxELWg3Y3qMipEIU91xzTH+F7bhY3S1yQkqllWY62PUSovfldrCNvvEzGHnPWlP4MGiwEsNXGZeGHzRZJ0yzq6bLjdUQa99VssJrF5S9HwGQ3GRQohyhKIn7P3N4J8ve7mWma7xudZGOb9KrokeE9xXoP8BXVbUT77Ky4yud+vlmN0xObbJErr3MGUOvRua0v7sSfdIUinlEnhSgBasCXh4TuA37QKwek3gfzJeHyLGFC9mFgdtwW+JA== Received: from [66.196.81.171] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2016 16:30:09 -0000 Received: from [98.139.212.224] by tm17.bullet.mail.bf1.yahoo.com with NNFMP; 18 Jan 2016 16:30:09 -0000 Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 18 Jan 2016 16:30:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 603022.5474.bm@omp1033.mail.bf1.yahoo.com X-YMail-OSG: kTWDatMVM1lhJzVg7wFGq.StAr55G2vNrNj6RAi4QLCjab0NJwgyoalj_1OcdOW K.VodwqfSRfIJ957eS49rOHfVD3C8yl2g7hCiYCiiPOvJ70qx..hnDUe1DIxdpEKmaXUiq9R_DcD tgTYl2xfQxVZcLfkshFZMzU9DuwGdwLnfREfMF9ulHJ6qyZn_rMkNaZsr9AZLMa_g439maPhcZOa enpgPw0gmBv4SVfwUhP.bkFoJ4aPQy8I8Urgc25lN_UzB6zcV9ftFblEd_rGLbK75R3Imw1oFZ3J U7k1XE.ZJBabBn22vD43lWMcdyuVuEqy1pd8JRaVd3rtt_V_kp6svGf_ntzfxwXd7LKNjqWr4XYW 6xqtFmxlZ06qx1HfpQ.5rBHUj99Ttb69gIoYLwOMh1sYGpRCb4.gL55l3G_TEg27EFoyj0KtDZ7n _aMVgUVgoeT0EFVI44SjTX277L0Atrw8L5RuuTloML9EyE23QULDKlkBAkTAy30kUOa23_NtR88n SMaq7LFZUHAetPHYrV1HTiDbk7kvuYhhDBXRPIOLVvynzHjBwomqPLW.Q6cPqck4TQpPID7ZeUzY Fw0lRjkXbfU6_3bdftRXoiBb7bohIMA-- Received: by 66.196.80.147; Mon, 18 Jan 2016 16:30:09 +0000 Date: Mon, 18 Jan 2016 16:30:08 +0000 (UTC) From: Eugene Yin Reply-To: Eugene Yin To: Andreas Joseph Krogh Cc: Postgres List Message-ID: <614277427.7358116.1453134608680.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: BYTEA MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7358115_2115974733.1453134608679" Content-Length: 14532 X-Pg-Spam-Score: -1.2 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org ------=_Part_7358115_2115974733.1453134608679 Content-Type: multipart/alternative; boundary="----=_Part_7358114_2117990895.1453134608670" ------=_Part_7358114_2117990895.1453134608670 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To understand it further, let me give an example that I have a group of pic= tures (assume they a set of house pictures, such as living room, bedroom, k= itchen, patio, yard, etc).=C2=A0 I first save them (larger size) to the DB.= =C2=A0 Then when the user retrieve them, the user first see a line-up of sm= all pics, then they pick and click one, the selected one will popup a large= r picture.=C2=A0 I have two ways to do this: 1) BYTEA 2) OID For BYTEA, the whole set of pictures (larger size) are retrieved (dumped) i= nto the memories on both the Java and Pg sides, occupying the same size as = the original picture is.=C2=A0 Hence taking up larger memories. For OID, it takes smaller memories on both Java and Pg sides (store the byt= e array in a buffer?).=C2=A0 Whenever the user clicks the smaller pic, it t= hen get the byte array from the buffer and display the larger (original) si= zed one, hence taking up less memories (avoiding the memory leaking)? Thanks Eugene =20 On Monday, January 18, 2016 7:51 AM, Andreas Joseph Krogh wrote: =20 P=C3=A5 mandag 18. januar 2016 kl. 16:40:26, skrev Eugene Yin : "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 P= DF files.=C2=A0 The size of each file is less than5 MB.=C2=A0 For such purp= ose, is BYTEA ok?=C2=A0 If not, then how about 1 MB each? =C2=A0Again, that depends. If you plan on having 1000 simultaneous users th= en having everything in memory might not be a good idea. Remember the memor= y consumed by the JVM is quite a lot more the the raw byte-size of each ima= ge/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" w= ill then clean up the Pg side? =C2=A0It will clean it up, if it's not referenced anymore. PG will clean up= its side 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 PG)?=C2=A0 If so, where is it kept? And how they are got cleaned up? =C2=A0As reading BLOBs (using the OID-type) really means your processing a = stream 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 = the GC when not referenced anymore), which often is much less than the whol= e BLOB.=C2=A0--Andreas Joseph KroghCTO / Partner - Visena ASMobile: +47 909= 56 963andreas@visena.comwww.visena.com=C2=A0 =20=20= ------=_Part_7358114_2117990895.1453134608670 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To unders= tand it further, let me give an example that I have a group of pictures (as= sume they a set of house pictures, such as living room, bedroom, kitchen, <= /span>patio, yard, etc).&nbs= p; I first save them (= larger size) to the DB.&nb= sp; Then when the user retrieve them, the user first see a line-up of sm= all pics, then they pick and click one, the selected one will popup a larger picture. <= /div>

I have two ways to do this:

1) BYTEA

2) OID<= /div>

For BYTEA, the whole set of pictures (larg= er size) are retrieved (dumped) into the memories on both the Java and Pg s= ides, occupying the same size as the original picture is.  Hence takin= g up larger memories.

For OID, it takes smaller memories on both Java and Pg sides (store the by= te array in a buffer?).  Whenever the user clicks the smaller pic, it = then get the byte array from the buffer and display the larger (original) s= ized one, hence taking up less memories (avoiding the memory leaking)?
<= /div>


Thanks


Eugene






<= div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, = Lucida Grande, sans-serif; font-size: 13px;">
On Mond= ay, January 18, 2016 7:51 AM, Andreas Joseph Krogh <andreas@visena.com&g= t; wrote:


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.
 
"whole byte-array is kept in memory, both in the JAVA-app and in PG"
 =
--I be= lieve in Java the GarbageCollector will clean it up (?).  "Who" will t= hen clean up the Pg side?
 
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).
 
 
"whole byte-array is kept in memory, both in the JAVA-app and in PG"
 =
--Does= that mean for the OID, byte-array is NOT kept in memory (of JAVA-ap= p or PG)?  If so, where is it kept? And how they are got cleaned up?
 
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.


= ------=_Part_7358114_2117990895.1453134608670-- ------=_Part_7358115_2115974733.1453134608679 Content-Type: image/png Content-Transfer-Encoding: base64 Content-Disposition: inline Content-ID: iVBORw0KGgoAAAANSUhEUgAAAIUAAAAYCAYAAADUIj6hAAAABHNCSVQICAgI fAhkiAAABzBJREFUaEPtmNFxHDcMhmVP3i1VECpvnjzkVIHWFfhcgVcVRKrA UgWRK/C6Al8H3lTgy0PGbzFdQc4VJP/HADs43q6kROeJNbOYgQACIAgCWJKn g4MZ5gxUGXh0U0b+SIuF9G+EWXj2Q15vbrE/NPtk9uub7Gfdt5mBx1NhqSEo 8HshjbEUtlO2yIM9tsx5dZP9rPt2MzDZFAqZE4LGcFjdsg3saQaHt7fY70X9 49OnaS+OZidDBkavD33157L4xaw2os+Mp/DAC10l2XhOCeStj0W5ajrJL8Wf Ci80Xgf9vVlrhg9yRONe/f7xI2vNsIcM7JwU9o6oGyJrLT8JOA1aX9sKP4wl 94bAniukEbo/n7YPmuTETzIab4Y9ZWCrKexd8M58lxPCvvD6aihfvexbEQoP YO8NQRO0JnddGO6FJYaVsBde7cXj7KRk4LsqDxQzCYeGsJNgaXZe+JXkyGgW INq3Gp+bHNILz+wEYs5qH1eJrouNrpDXtk4O6x1IvtD40GWyJYYdkF0jIbYZ lN16xygIgl9smbMDsmFdfAKb23xGB8H/mv3tOJfArs1kukk79DEPdQ5u0g1v CvvqKXIW8mZYW+F3Tg4r8HvZkQCCLydK8EFMQCe5N8RgL9mRG0SqQFuNvdE6 beSs0qPDBuCdg0+gvClso8SbTO4ki7mQzQqBrcMHQPwReg2wW8umEe/+L8T/ LEzBGF9nXjzZ46s+ITHvhegW8LL39xm6App7KYL/GE+vcYnFbJiP/0aYhdiC nRC7jaj7eiK2ETInC5PRF6LYkSN0+HabF75WuT6syCyI0YkVGGMvUC33AmfZ TDUEj8u6IVhuEhRUJ2U2g6UlugyNb03Hl9obHwlxJbcRzcYjO4QPjVfGFTQa v4vrmp7cpMp2qbHnBxWJbisbho2QXI6C1sIHDUFhH4Hij4UbIev66eANeiwb kA+LBsO36zAHzoXU7AhbqLAXEiOYTXcSdO8VS9L4wN8UBIYhBd6oSUgYMijO kecRuTdQa/YiBXhbXFcnCnI2SrfeBG9NydrLYMhGHa5qB9pQIxlzAE6Okjzx JO5afGe6kmhBicWKQNKuTZ5EW+MjQY8v/9rQ0bhJSJyNGUe/JH1t8h1iMbdS PAvxHYin6YmN9YBXQmTYZZNh14vHhhhal5vtcIrJjmvszPRJdExH3MWHvyko BEc9CoCGWJisOLOGoCORs1FvIMbYA8z3kwM59oemy6LlWrLxFLmWgiQAfEGd 8S+NssbK+EhyGLxUkhhiy717waBqHOJYSEacwBejkFNhjJNjv/gANOdQxPfc iP/JVBCK2cOIcg3RRJ+CPrLPNVhhN6F38VKMF3XLlIJrjU5C8gMFxvKDvOcP c4rVNjCn7KM0BV+161V8viSCuJZ8SITGJGEh7IUUlxOFMYUH1kJOCN4Wh+I5 pqCuK01k40kSNtnKiKIlUfxAgW5sU5JlS05rtt5YFJF1SWoqHv6BRgQcA4/b db9WRjmMk3jyUMAbIoyJq9e4cVmgzKt9j5gNJ/aYDhk+hhjExwaPcz5PObA5 Zd9bvz5UzCTZuZDidu5AchpiKSwPR+TV1bCWqBQ9nCjJ5neivC82Nr4LeS2j 1gw5LUqwBuhGQQU5UwHeSslXkwIynz2U2A2yKDgG7OffwLA3TpGRpk0Tzpj3 ZEJXi/GRa6GN0e0NtppChePdcAz1FTS+FN8Kpxoiykk+J8fC5tenjbu9kSqp HLu9jBrhUuhNwVGbpyZrzrl0HPVD8SXj5EOOD/eDC64VjvYBZLuUbIVAfBN1 t/C/SU+cAGtdGo+fVnzycUX5wmn6eCKPmWYJG2E/ppTsuRCbvUD9fwquksG5 GqLVKhzDQ3GrEyLKSXhsiK3T5j9EyxffCFOYi2wUlPyFFDQAhehESDjQGoX0 ho0oj8RPou6TxHJdcT0NTcWkO0AnG7+uXsnHqcas/72wvWF+mSf7N/Watp9k TXoluzeS0fB99CcZ/hvhSZTfh99pispZOXL9KrGrARkNUMu9ITbScZWs7xOY Nt9pwxSZtYDsX/GE3xTkrXgwAsXmfud08FiTeC+m2/o7ppo+PTS/NBK5ARpD G5YHr++DpmVfreYdiX8mnp+DzPEG9WbqJON0JBenZofssxBA1gj5NXGvfJu/ Qh7HwQh/VDUEyUxCit5hH94QfKkEdu+GwK8BX0hvCF+D67xhjmXQCXMwJCZ+ olK0A1EKRCE4snsh42w8Mv/Zhxw9iD7Cjo7CyQC/KyF6oBfShL4PYgG+CHsY KyZxvxZSZBAgjhIzYDz+AbfD37GtbaoSKzgGt+lKfI/GZtay6vG4VXTpPsh+ IcQhOk9I7WYeP5AM3HZ9+DaSGIp9HIuuhuC4pCGGx+YD2fcc5tfIAA0h/Et4 /jX8zz4fWAasIf4UbR9Y6HO4d8jAnd4U0Y8ageuCB+c+H5R3CHU2mTMwZ+B/ y8DfSMBLLOYXVuEAAAAASUVORK5CYII= ------=_Part_7358115_2115974733.1453134608679 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql ------=_Part_7358115_2115974733.1453134608679--