Re: TEXT column > 1Gb

From: Benedict Holland <benedict(dot)m(dot)holland(at)gmail(dot)com>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: TEXT column > 1Gb
Date: 2023-04-12 20:28:10
Message-ID: CAD+mzoxFxj6S38YNeZF3ybg+pmGFmSjY=WYNyyc2_Q-nPTU63w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Yea. For ease of use, out of the box solutions that will just work, large
objects. You might know them as BLOBS in other SQL varieties. If you are
dealing with that much data, I'm going to assume that storage isn't really
your concern. I wouldn't even waste time compressing. I use them frequently
to store all sorts of wierd objects like pictures or serialized pickle
files. They are really fast and extremely easy to use. They do not play
nicely with a lot of 3rd party software, particularly UIs sitting on top of
a database but again, if that isnt a concern or you can use stored
procedures for the selects, it should be just fine.

On Wed, Apr 12, 2023, 3:21 PM Rob Sargent <robjsargent(at)gmail(dot)com> wrote:

> On 4/12/23 13:02, Ron wrote:
>
> *Must* the genome all be in one big file, or can you store them one line
> per table row?
>
>
> Not sure what OP is doing with plant genomes (other than some genomics)
> but the tools all use files and pipeline of sub-tools. In and out of
> tuples would be expensive. Very,very little "editing" done in the usual
> "update table set val where id" sense.
>
> Lines in a vcf file can have thousands of colums fo nasty, cryptic garbage
> data that only really makes sense to tools, reader. Highly denormalized of
> course. (Btw, I hate sequencing :) )
>
>
>
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ron 2023-04-12 20:29:10 Re: TEXT column > 1Gb
Previous Message Rob Sargent 2023-04-12 19:21:12 Re: TEXT column > 1Gb