Re: pg_largeobject

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
>>
>
>

In response to

Responses

Browse pgsql-general by date

  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

Browse pgsql-hackers by date

  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