Обсуждение: TEXT column > 1Gb

Hello,

I’ve recently encountered the issue of trying to insert more than 1 Gb into a TEXT column. While the docs say TEXT is
unlimitedlength, I had been unaware of the 1Gb buffer size limitations. 

We can debate whether or not saving something this big in a single column is a good idea (spoiler: it isn’t. But not my
designand, in fairness, was not anticipated when the schema was designed.), I’d like to implement something that is not
amajor disruption and try to keep the mods on the server side. My first idea is to have a chunked associated table (in
pseudocode) 

CREATE TABLE associated(key_id integer references main_table(key_id), chunk integer, text_start integer, text_end
integer,text_chunk TEXT); 

And define functions for inserting and selecting by dividing into 1Mb chunks

CREATE FUNCTION insertText(INTEGER,TEXT) RETURNS INTEGER AS $$
DECLARE
  chunk INTEGER := 0;
  key_id ALIAS for $1;
  the_text ALIAS for $2;
  text_chunk TEXT;
BEGIN
  LOOP
    text_chunk := substr(the_text,chunk*1000000,1000000);
    IF length(text_chunk) = 0 THEN
      EXIT;
    END IF;
    INSERT INTO associated(key_id,chunk,text_start,text_end,text_chunk) VALUES
(key_id,chunk,chunk*1000000,(chunk*1000000+length(text_chunk)),text_chunk);
    chunk := chunk + 1;
  END LOOP;
  RETURN chunk;
END;
$$ LANGUAGE plpgsql;

This apparently runs into the same issues of buffers size: I get an ‘invalid message length’ in the log file and the
insertfails. I can see from adding notices in the code that I never enter the LOOP; I assume having function arguments
>1Gb is also a bad thing. 

I’d like to continue to keep the modifications on the server size. And I’d like to believe someone else has had this
problembefore. Any suggestions other than have the client do the chunking? Can I use a different language binding and
getaround the argument length limitations? 

Thanks

Hello,

I’ve recently encountered the issue of trying to insert more than 1 Gb into a TEXT column. While the docs say TEXT is unlimited length, I had been unaware of the 1Gb buffer size limitations.

We can debate whether or not saving something this big in a single column is a good idea (spoiler: it isn’t. But not my design and, in fairness, was not anticipated when the schema was designed.), I’d like to implement something that is not a major disruption and try to keep the mods on the server side. My first idea is to have a chunked associated table (in pseudo code)

CREATE TABLE associated(key_id integer references main_table(key_id), chunk integer, text_start integer, text_end integer, text_chunk TEXT);

And define functions for inserting and selecting by dividing into 1Mb chunks

CREATE FUNCTION insertText(INTEGER,TEXT) RETURNS INTEGER AS $$
DECLARE  chunk INTEGER := 0;  key_id ALIAS for $1;  the_text ALIAS for $2;  text_chunk TEXT;
BEGIN  LOOP    text_chunk := substr(the_text,chunk*1000000,1000000);    IF length(text_chunk) = 0 THEN      EXIT;    END IF;    INSERT INTO associated(key_id,chunk,text_start,text_end,text_chunk) VALUES (key_id,chunk,chunk*1000000,(chunk*1000000+length(text_chunk)),text_chunk);    chunk := chunk + 1;  END LOOP;  RETURN chunk;
END;
$$ LANGUAGE plpgsql;

This apparently runs into the same issues of buffers size: I get an ‘invalid message length’ in the log file and the insert fails. I can see from adding notices in the code that I never enter the LOOP; I assume having function arguments > 1Gb is also a bad thing.

I’d like to continue to keep the modifications on the server size. And I’d like to believe someone else has had this problem before. Any suggestions other than have the client do the chunking? Can I use a different language binding and get around the argument length limitations?

Thanks



On 4/11/23 11:41, Joe Carlson wrote:

Hello,

I’ve recently encountered the issue of trying to insert more than 1 Gb into a TEXT column. While the docs say TEXT is unlimited length, I had been unaware of the 1Gb buffer size limitations.

We can debate whether or not saving something this big in a single column is a good idea (spoiler: it isn’t. But not my design and, in fairness, was not anticipated when the schema was designed.), I’d like to implement something that is not a major disruption and try to keep the mods on the server side. My first idea is to have a chunked associated table (in pseudo code)

CREATE TABLE associated(key_id integer references main_table(key_id), chunk integer, text_start integer, text_end integer, text_chunk TEXT);

And define functions for inserting and selecting by dividing into 1Mb chunks

CREATE FUNCTION insertText(INTEGER,TEXT) RETURNS INTEGER AS $$
DECLARE  chunk INTEGER := 0;  key_id ALIAS for $1;  the_text ALIAS for $2;  text_chunk TEXT;
BEGIN  LOOP    text_chunk := substr(the_text,chunk*1000000,1000000);    IF length(text_chunk) = 0 THEN      EXIT;    END IF;    INSERT INTO associated(key_id,chunk,text_start,text_end,text_chunk) VALUES (key_id,chunk,chunk*1000000,(chunk*1000000+length(text_chunk)),text_chunk);    chunk := chunk + 1;  END LOOP;  RETURN chunk;
END;
$$ LANGUAGE plpgsql;

This apparently runs into the same issues of buffers size: I get an ‘invalid message length’ in the log file and the insert fails. I can see from adding notices in the code that I never enter the LOOP; I assume having function arguments > 1Gb is also a bad thing.

I’d like to continue to keep the modifications on the server size. And I’d like to believe someone else has had this problem before. Any suggestions other than have the client do the chunking? Can I use a different language binding and get around the argument length limitations?

Thanks

I've hit this same limitation in Java (with write to db).  What is your stack in this case?  Not sure my solution applies.

On 4/12/23 08:59, Joe Carlson wrote:
> I’m curious what you learned. I’ve been tripping over the buffer 
> allocation issue when either splitting input text into chunks or 
> aggregating chunks in selects. I’ve decided that I need to move this 
> to client side.
>
> The use case is genomics. Extracting substrings is common. So going to 
> chunked storage makes sense.
>
> And we have a menagerie of code to deal with. Legacy Perl for loading. 
> Clients in Perl, Java, node, python. A whole zoo.
>
> Thanks

My first stab was a java implementation based Selector class which 
worked ok using a fixed buffer size but finding the end of last 
transmission was hokey.  I move to an embedded Tomcat implementation and 
tomcat does the heavy lifting PERFECTLY.  Easily slipped in to both 
client and backend.

rjs

> On Apr 12, 2023, at 7:59 AM, Joe Carlson <jwcarlson@lbl.gov> wrote:
>
> The use case is genomics. Extracting substrings is common. So going to chunked storage makes sense.

Are you storing nucleotide sequences as text strings?  If using the simple 4-character (A,C,G,T) alphabet, you can
storefour bases per byte.  If using a nucleotide code 16-character alphabet you can still get two bases per byte.  An
aminoacid 20-character alphabet can be stored 8 bases per 5 bytes, and so forth.  Such a representation might allow you
tostore sequences two or four times longer than the limit you currently hit, but then you are still at an impasse.
Woulda factor or 2x or 4x be enough for your needs?  

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

I’ve certainly thought about using a different representation. A factor of 2x would be good, for a while anyway. For
nucleotidesequence, we’d need to consider a 10 character alphabet (A, C, G, T, N and the lower case forms when
representing’soft masked’ sequence*). So it would be 2 bases/byte. (Proteins are not nearly so long so a straight
storageis simpler.) But these would be bigger changes on the client side than storing in chunks so I think this is the
wayto go. 

We’re working with plant genomes, which compared to human chromosomes, are HUGE. One chromosome of fava bean is over a
gig.And pine tree is another monster. This, together with the fact that sequence data collection and assembly have
improvedso much in the past couple years has forced us to rethink a lot of our data storage assumptions.  

* for those curious, especially in plants, much of sequence consists of repetitive element that are remnants of ancient
viruses,simple repeats and the like. For people who want to identify particular functional components in a genome, they
typicallydo not want to search against this sequence but restrict searching to coding regions. But the repetitive
sequenceis still important and we need to keep it. 

> On Apr 12, 2023, at 10:04 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
>> On Apr 12, 2023, at 7:59 AM, Joe Carlson <jwcarlson@lbl.gov> wrote:
>>
>> The use case is genomics. Extracting substrings is common. So going to chunked storage makes sense.
>
> Are you storing nucleotide sequences as text strings?  If using the simple 4-character (A,C,G,T) alphabet, you can
storefour bases per byte.  If using a nucleotide code 16-character alphabet you can still get two bases per byte.  An
aminoacid 20-character alphabet can be stored 8 bases per 5 bytes, and so forth.  Such a representation might allow you
tostore sequences two or four times longer than the limit you currently hit, but then you are still at an impasse.
Woulda factor or 2x or 4x be enough for your needs?  
>
> —
> Mark Dilger
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
>

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 :( .

I’ve certainly thought about using a different representation. A factor of 2x would be good, for a while anyway. For nucleotide sequence, we’d need to consider a 10 character alphabet (A, C, G, T, N and the lower case forms when representing ’soft masked’ sequence*). So it would be 2 bases/byte. (Proteins are not nearly so long so a straight storage is simpler.) But these would be bigger changes on the client side than storing in chunks so I think this is the way to go.

We’re working with plant genomes, which compared to human chromosomes, are HUGE. One chromosome of fava bean is over a gig. And pine tree is another monster. This, together with the fact that sequence data collection and assembly have improved so much in the past couple years has forced us to rethink a lot of our data storage assumptions. 

* for those curious, especially in plants, much of sequence consists of repetitive element that are remnants of ancient viruses, simple repeats and the like. For people who want to identify particular functional components in a genome, they typically do not want to search against this sequence but restrict searching to coding regions. But the repetitive sequence is still important and we need to keep it.

On Apr 12, 2023, at 10:04 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:

On Apr 12, 2023, at 7:59 AM, Joe Carlson <jwcarlson@lbl.gov> wrote:

The use case is genomics. Extracting substrings is common. So going to chunked storage makes sense.

Are you storing nucleotide sequences as text strings?  If using the simple 4-character (A,C,G,T) alphabet, you can store four bases per byte.  If using a nucleotide code 16-character alphabet you can still get two bases per byte.  An amino acid 20-character alphabet can be stored 8 bases per 5 bytes, and so forth.  Such a representation might allow you to store sequences two or four times longer than the limit you currently hit, but then you are still at an impasse.  Would a factor or 2x or 4x be enough for your needs? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Must the genome all be in one big file, or can you store them one line per table row?

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

On Apr 12, 2023, at 12:21 PM, Rob Sargent <robjsargent@gmail.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?

The assumption in the schema I’m using is 1 chromosome per record. Chromosomes are typically strings of continuous sequence (A, C, G, or T) separated by gaps (N) of approximately known, or completely unknown size. In the past this has not been a problem since sequenced chromosomes were maybe 100 megabases. But sequencing is better now with the technology improvements and tackling more complex genomes. So gigabase chromosomes are common. 

A typical use case might be from someone interested in seeing if they can identify the regulatory elements (the on or off switches) of a gene. The protein coding part of a gene can be predicted pretty reliably, but the upstream untranslated region and regulatory elements are tougher. So they might come to our web site and want to extract the 5 kb bit of sequence before the start of the gene and look for some of the common motifs that signify a protein binding site. Being able to quickly pull out a substring of the genome to drive a web app is something we want to do quickly.