| From: | Rob Sargent <robjsargent(at)gmail(dot)com> |
|---|---|
| To: | Benedict Holland <benedict(dot)m(dot)holland(at)gmail(dot)com>, Joe Carlson <jwcarlson(at)lbl(dot)gov> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: TEXT column > 1Gb |
| Date: | 2023-04-12 17:37:18 |
| Message-ID: | 51512362-ab2d-e927-d520-4bd67517273b@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 4/12/23 11:24, Benedict Holland wrote:
> For documents that long I would seriously consider using large objects
> and refencing them with their OIDs. Text fields get put in a special
> location within the database. It's similar (possibly exactly) to using
> large objects. Also, you can potentially compress them to save space
> on write and read. 1gb of text is a lot of text.
>
I've gone down the premature optimization coded/compressed route and am
still regretting it. I would either not bother or move to LO as per
Benedict's suggestion. The test may come to whether you plan to use
database features (functions, procedures) to work on the data versus
feeding it out to the endless list of sequence/genetic analysis tools.
General compression is robust and fast. My custom code/comp is likely
neither :( .
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron | 2023-04-12 19:02:25 | Re: TEXT column > 1Gb |
| Previous Message | Benedict Holland | 2023-04-12 17:24:34 | Re: TEXT column > 1Gb |