Re: Large Objects
От | Dan Boitnott |
---|---|
Тема | Re: Large Objects |
Дата | |
Msg-id | AEC4C07E-5C60-11D9-83B8-000D932E24AA@mcneese.edu обсуждение исходный текст |
Ответ на | Re: Large Objects ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: Large Objects
Re: Large Objects |
Список | pgsql-general |
On Jan 1, 2005, at 11:40 AM, Joshua D. Drake wrote: > >>> >> Intresting. >> What is the size when bytea become inafective ? >> >> Currently i keep all my products images in bytea record. is it >> practical ? > > Well I am going to make the assumption that you product images are > small... > sub 100k or something. Bytea is just fine for that. The problem is when > the binary you want to store is 50 megs. When you access that file you > will be using 50 megs of ram to do so. > > Large Objects don't work that way, you don't have the memory overhead. > So > it really depends on what you want to store. > I prefer the _idea_ of using large objects but am worried about the implications. Without them I can back up the database using pg_dump and get a single tar file which can perfectly represent the database. This gives me (and those on high) the warm-fuzzies. If I store files (PDFs of varying sizes by the way, say from 500k to 50M) as large objects, will I still be able to restore the _whole_ database from a single pg_dump tar file? > >> >> how slower is it then accessing an image on a file system ( like ext3 >> ) ? > > Well that would be an interesting test. Ext3 is very slow. I would > assume > that Ext3 would be faster just because of the database overhead. > However you gain from having the images in the database for > flexibility and manageability. > > Sincerely, > > Joshua D. Drake > > > >> >> >> Cheers >> >>> >>> pg_largeobject is more efficient than BYTEA for larger binaries. >>> >>> Sincerely, >>> >>> Joshua D. Drake >>> >>> >> > > > -- > 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 > > <jd.vcf> > ---------------------------(end of > broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
В списке pgsql-general по дате отправления: