Re: Large Objects

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Michael Ben-Nes <miki(at)canaan(dot)co(dot)il>
Cc: "Frank D(dot) Engel, Jr(dot)" <fde101(at)fjrhome(dot)net>, pgsql general list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Large Objects
Date: 2005-01-01 17:40:09
Message-ID: 41D6E079.7030309@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


>>
> 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.

>
> 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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Attachment Content-Type Size
jd.vcf text/x-vcard 285 bytes

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message John Smith 2005-01-01 23:37:40 Re: ECPG Segfaulting on EXEC SQL connect
Previous Message Martijn van Oosterhout 2005-01-01 15:48:46 Re: Large Objects