Re: bytea and text
От | Syan Tan |
---|---|
Тема | Re: bytea and text |
Дата | |
Msg-id | 44963.1259366406@people.net.au обсуждение исходный текст |
Ответ на | bytea and text ("Jean-Yves F. Barbier" <12ukwn@gmail.com>) |
Список | pgsql-novice |
Not sure if decode works for COPY statements though, I thought copy is faster than insert for bulk loading lots of data than using a client call in whatever language postgres driver. But then its only one field for binary data which is a lot bigger than the other fields in the tuple, so I'm not sure what is the rate-limiting factor here. On Fri 27/11/09 14:18 , "Jean-Yves F. Barbier" 12ukwn@gmail.com sent: > Jasen Betts a écrit : > > On 2009-11-26, Jean-Yves F. Barbier <12ukwn@gmail > .com> wrote:>> Hi list, > >> > >> I'm asking myself what solution for storing > pictures is the best:>> > >> * using a BYTEA column type, and having no > intrinsic compression gain >> because a picture it almost every time > already compressed,>> > >> * using a TEXT column type, and store a > Base64(picture) in it; it should>> take benefits of intrinsic compression > (?).> > > use bytea and convert to/from base64 if you > can't use the binary> interface and find the text interface > inconvenient. > that's what I do now > > > this will make the data over 1/3 > bigger. > uuu, na: it comes as Base64 (to avoid a 0x89 unknown utf8 char error), but > itis converted to BYTEA as I now use decode('inparm', 'base64') before > insert,as back to Base64 when I extract it (with encode). > > -- > * JHM wonders what Joey did to earn "I'd just like to say, for the > record,that Joey rules." > -- Seen on #Debian > > -- > Sent via pgsql-novice mailing list (p > gsql-novice@postgresql.org)To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-novice > >
В списке pgsql-novice по дате отправления: