Re: long transfer time for binary data
От | Johannes |
---|---|
Тема | Re: long transfer time for binary data |
Дата | |
Msg-id | 56A40917.1070705@posteo.de обсуждение исходный текст |
Ответ на | Re: long transfer time for binary data (John R Pierce <pierce@hogranch.com>) |
Список | pgsql-general |
Am 23.01.2016 um 23:38 schrieb John R Pierce: > On 1/23/2016 2:19 PM, Johannes wrote: >> I save my images as large object, which afaik is in practise not >> readable with a binary cursor (we should use the lo_* functions). And of >> course I already use the LargeObjectManager of the postgresql jdbc >> library. > > > afaik, Large Objects are completely independent of the other mode > stuff. they are stored and transmitted in binary. Depends on the client. It can be transfered as text or binary. And the data is sliced into bytea segements [1] and afaik it is stored as binary string. > I haven't read this whole ongoing thread, just glanced at messages as > they passed by over the past week or whatever, but I have to say, I > would NOT be storing 11MB images directly in SQL, rather, I would store > it on a file server, and access it with nfs or https or whatever is most > appropriate for the nature of the application. I would store the > location and metadata in SQL. The 11MB file is the biggest image one, the rest is normal. I know about the arguments, but there are pros I want to use in production (transactions, integrity). But if it fails (amount of space?, slow import?) I may exclude the image data. [1] http://www.postgresql.org/docs/9.5/static/catalog-pg-largeobject.html
Вложения
В списке pgsql-general по дате отправления: