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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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 | Content-Type | Size |
---|---|---|
jd.vcf | text/x-vcard | 285 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2004-12-31 17:43:26 | Re: 'distinct on' and 'order by' conflicts of interest |
Previous Message | Michael Fuhr | 2004-12-31 17:36:36 | Re: 'distinct on' and 'order by' conflicts of interest |