From: | Sridhar N Bamandlapally <sridhar(dot)bn1(at)gmail(dot)com> |
---|---|
To: | Alvaro Aguayo Garcia-Rada <aaguayo(at)opensysperu(dot)com> |
Cc: | John R Pierce <pierce(at)hogranch(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_largeobject |
Date: | 2016-03-29 15:09:10 |
Message-ID: | CAGuFTBWe6n1ddcZ=CxBXtdQbHfyb0XHjjXgkkgupxNXrk3LzkA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
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 | Alvaro Aguayo Garcia-Rada | 2016-03-29 15:20:27 | Re: pg_largeobject |
Previous Message | Melvin Davidson | 2016-03-29 13:13:14 | Re: More correlated (?) index woes |
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2016-03-29 15:09:24 | Re: BUG #13854: SSPI authentication failure: wrong realm name used |
Previous Message | David Steele | 2016-03-29 15:04:46 | Re: Speedup twophase transactions |