Re: BYTEA - Mailing list pgsql-sql

From Andreas Joseph Krogh
Subject Re: BYTEA
Date
Msg-id VisenaEmail.ca.3430189fb000a7e8.152556785e6@tc7-visena
Whole thread Raw
In response to Re: BYTEA  (Eugene Yin <eugeneymail@ymail.com>)
Responses Re: BYTEA
List pgsql-sql
På mandag 18. januar 2016 kl. 16:40:26, skrev Eugene Yin <eugeneymail@ymail.com>:
"if you only work with small-ish binary data, yes - BYTEA does the job."
 
--The goal is to save/retrieve the user's photos (JPEG, TIFF, GIF) and PDF files.  The size of each file is less than
5 MB.  For such purpose, is BYTEA ok?  If not, then how about 1 MB each?
 
Again, that depends. If you plan on having 1000 simultaneous users then 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 image/blob.
 
"whole byte-array is kept in memory, both in the JAVA-app and in PG"
 
--I believe in Java the GarbageCollector will clean it up (?).  "Who" will then 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-app 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 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 whole BLOB.
 
--
Andreas Joseph Krogh
CTO / Partner - Visena AS
Mobile: +47 909 56 963
 
Attachment

pgsql-sql by date:

Previous
From: Eugene Yin
Date:
Subject: Re: BYTEA
Next
From: Eugene Yin
Date:
Subject: Re: BYTEA