From: | Jerome Wagner <jerome(dot)wagner(at)laposte(dot)net> |
---|---|
To: | PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_largeobject |
Date: | 2016-03-29 15:56:10 |
Message-ID: | CA+=V_fOYWDup+iDiJKRNEpyscEf6w7tKwmPu_MP05z5atk7=YQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
I am not saying that this will solve your problem (I never tried id even
though I keep it in my radar), but this project seems to implement
something close to what Daniel is describing:
https://github.com/andreasbaumann/pgfuse
+ it gives you a FUSE wrapper so the client can use fs calls.
the proposed schema is here
https://github.com/andreasbaumann/pgfuse/blob/master/schema.sql
On Tue, Mar 29, 2016 at 5:09 PM, Sridhar N Bamandlapally <
sridhar(dot)bn1(at)gmail(dot)com> wrote:
> We are doing application/database migration compatible with postgresql on
> cloud, DR/replication also in plan
>
> at present I feel need of configurable multi-table storage instead of
> pg_largeobject only
>
> Thanks
> Sridhar
>
>
> On Tue, Mar 29, 2016 at 6:08 PM, Alvaro Aguayo Garcia-Rada <
> aaguayo(at)opensysperu(dot)com> wrote:
>
>> Some time ago I had to setup a replicated file system between multiple
>> linux servers. I tried everything I could based on postgres, including
>> large objects, but everything was significantly slower than a regular
>> filesystem.
>>
>> My conclussion: postgres is not suitable for storing large files
>> efficiently.
>>
>> Do you need that for replication, or just for file storage?
>>
>> Alvaro Aguayo
>> Jefe de Operaciones
>> Open Comb Systems E.I.R.L.
>>
>> Oficina: (+51-1) 3377813 | RPM: #034252 / (+51) 995540103 | RPC:
>> (+51) 954183248
>> Website: www.ocs.pe
>>
>> Sent from my Sony Xperia™ smartphone
>>
>>
>> ---- Sridhar N Bamandlapally wrote ----
>>
>>
>> all media files are stored in database with size varies from 1MB - 5GB
>>
>> based on media file types and user-group we storing in different tables,
>> but PostgreSQL store OID/Large-object in single table (pg_largeobject), 90%
>> of database size is with table pg_largeobject
>>
>> due to size limitation BYTEA was not considered
>>
>> Thanks
>> Sridhar
>>
>>
>>
>> On Tue, Mar 29, 2016 at 3:05 PM, John R Pierce <pierce(at)hogranch(dot)com>
>> wrote:
>>
>>> On 3/29/2016 2:13 AM, Sridhar N Bamandlapally wrote:
>>>
>>>> Hi
>>>>
>>>> pg_largeobject is creating performance issues as it grow due to single
>>>> point storage(for all tables)
>>>>
>>>> is there any alternate apart from bytea ?
>>>>
>>>> like configuration large-object-table at table-column level and oid
>>>> PK(primary key) stored at pg_largeobject
>>>>
>>>>
>>> I would as soon use a NFS file store for larger files like images,
>>> audio, videos, or whatever. use SQL for the relational metadata.
>>>
>>> just sayin'....
>>>
>>>
>>>
>>> --
>>> john r pierce, recycling bits in santa cruz
>>>
>>>
>>>
>>> --
>>> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-general
>>>
>>
>>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-03-29 17:38:43 | Re: How to quote the COALESCE function? |
Previous Message | Daniel Verite | 2016-03-29 15:31:13 | Re: pg_largeobject |
From | Date | Subject | |
---|---|---|---|
Next Message | Petr Jelinek | 2016-03-29 15:57:00 | Re: WIP: Access method extendability |
Previous Message | Shulgin, Oleksandr | 2016-03-29 15:54:05 | Re: More stable query plans via more predictable column statistics |