Skip site navigation (1) Skip section navigation (2)

Re: Large Objects

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: "Frank D(dot) Engel, Jr(dot)" <fde101(at)fjrhome(dot)net>
Cc: pgsql general list <pgsql-general(at)postgresql(dot)org>
Subject: Re: Large Objects
Date: 2004-12-31 17:40:27
Message-ID: 41D58F0B.7020608@commandprompt.com (view raw or flat)
Thread:
Lists: 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(at)mcneese(dot)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(at)fjrhome(dot)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(at)postgresql(dot)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(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment: jd.vcf
Description: text/x-vcard (285 bytes)

In response to

Responses

pgsql-general by date

Next:From: Stephan SzaboDate: 2004-12-31 17:43:26
Subject: Re: 'distinct on' and 'order by' conflicts of interest
Previous:From: Michael FuhrDate: 2004-12-31 17:36:36
Subject: Re: 'distinct on' and 'order by' conflicts of interest

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group