From: | Дмитрий Иванов <firstdismay(at)gmail(dot)com> |
---|---|
To: | Estevan Rech <softrech(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Rob Sargent <robjsargent(at)gmail(dot)com>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Best Strategy for Large Number of Images |
Date: | 2021-12-16 01:50:55 |
Message-ID: | CAPL5KHpAFwAF5rsC+3=J+3QZR_WHoEvdqEPyeCyT4tBrNmBXgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
PostgreSQL, thanks to extensions, allows a third non-obvious file strategy.
Since many developers when working with small images don't want to overload
their solutions with the complexities of interacting with file servers, and
I didn't want to store files in a database, I found and tried a third
option. I turned PostgreSQL into a file server that provides page bytes
exchange with the client using Bytea virtual tables. Roughly it looks like
this: client-(access library-asynchronous page
exchange)-PostgreSQL-Python-file system. I've set a limit of 2Gb, but
working with such large files with this strategy doesn't seem reasonable to
me. But the system for storing fiscal documents turned out pretty good
(<10Mb).
--
Regards, Dmitry!
ср, 15 дек. 2021 г. в 23:18, Estevan Rech <softrech(at)gmail(dot)com>:
> I think about using it inside the database to facilitate the select and
> generation of reports...
>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Matt Magoffin | 2021-12-16 02:11:12 | Re: Properly handling aggregate in nested function call |
Previous Message | Tom Lane | 2021-12-16 01:43:21 | Re: Properly handling aggregate in nested function call |