Re: Large Objects

From: Dan Boitnott <dan(at)mcneese(dot)edu>
To: pgsql general list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Large Objects
Date: 2005-01-02 01:50:30
Message-ID: AEC4C07E-5C60-11D9-83B8-000D932E24AA@mcneese.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)commandprompt(dot)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(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Jeff Davis 2005-01-02 02:11:49 Re: many similar indexbased selects are extremely slow
Previous Message Jeff Davis 2005-01-02 01:34:08 Re: many similar indexbased selects are extremely slow