Re: Large Objects

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: Large Objects
Дата
Msg-id 41D58F0B.7020608@commandprompt.com
обсуждение исходный текст
Ответ на Re: Large Objects  ("Frank D. Engel, Jr." <fde101@fjrhome.net>)
Ответы Re: Large Objects
Список 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@mcneese.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@fjrhome.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@postgresql.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@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Fuhr
Дата:
Сообщение: Re: 'distinct on' and 'order by' conflicts of interest
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: 'distinct on' and 'order by' conflicts of interest