Re: Large Objects - Mailing list pgsql-general
From | Joshua D. Drake |
---|---|
Subject | Re: Large Objects |
Date | |
Msg-id | 41D58F0B.7020608@commandprompt.com Whole thread Raw |
In response to | Re: Large Objects ("Frank D. Engel, Jr." <fde101@fjrhome.net>) |
Responses |
Re: Large Objects
|
List | pgsql-general |
Frank D. Engel, Jr. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'd advise use of BYTEA as well. It's much simpler to work with than > the OIDs, and has simpler semantics. You do need to escape data > before handing it to the query string, and handle escaped results (see > the docs), but overall much nicer than working with OIDs. BYTEA is not always pragmatic. What is the file is 100 megs? 256 megs? pg_largeobject is more efficient than BYTEA for larger binaries. Sincerely, Joshua D. Drake > > On Dec 31, 2004, at 1:21 AM, Bruno Wolff III wrote: > >> On Mon, Dec 27, 2004 at 10:39:48 -0600, >> Dan Boitnott <dan@mcneese.edu> wrote: >> >>> I need to do some investigation into the way Postgres handles large >>> objects for a major project involving large objects. My questions are: >> >> >> I don't know the answer to all of your questions. >> >>> * Is it practical/desirable to store files MIME-Encoded inside a >>> text field? >> >> >> This should be possible if the files aren't too large. bytea is >> another type >> that might be better to use. >> >>> * The obvious disadvantages: >>> * slow, Slow, SLOW >> >> >> If you always need to access the whole file this might not be too bad. >> But if you only need to access a small part, you are going to pay a big >> cost as the whole record will need to be retrieved before you can pick >> out the part you want. >> >>> * significant increase in per-file storage requirements >> >> >> It might not be too bad as large records can be compressed. That >> should get >> back some of the bloat from uuencoding. >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 9: the planner will ignore your desire to choose an index scan if >> your >> joining column's datatypes do not match >> >> > - ----------------------------------------------------------- > Frank D. Engel, Jr. <fde101@fjrhome.net> > > $ ln -s /usr/share/kjvbible /usr/manual > $ true | cat /usr/manual | grep "John 3:16" > John 3:16 For God so loved the world, that he gave his only begotten > Son, that whosoever believeth in him should not perish, but have > everlasting life. > $ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFB1XbY7aqtWrR9cZoRAp6PAJ0UMNDpfeiI2iUaAp3CMIyaxuJNgQCffoqJ > mn4M418e7V9YZX5fwte9Ra0= > =iXtd > -----END PGP SIGNATURE----- > > > > ___________________________________________________________ > $0 Web Hosting with up to 120MB web space, 1000 MB Transfer > 10 Personalized POP and Web E-mail Accounts, and much more. > Signup at www.doteasy.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Attachment
pgsql-general by date: