Support for huge records that span more than one data page

[eolivelli]

FEATURE REQUEST

1. Please describe the feature you are requesting.
   Currently (0.18.0) a record must fit entirely in a data page, if you have huge records you have to configure the server to use a huge page size, with a bad impact on swapping.

2. Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have). Are you currently using any workarounds to address this issue?
   should-have

3. Provide any additional detail on your proposed use case for this feature.
   We could split the record and save as "value" a list of pointers to data pages on an additional hidden system table.

example:
on table Table1
key1 -> veryhugerecord

on PK:
key1 -> idpage 1

in idpage1 we have:
key1 -> list of pointers to Table1_hugerecords

• offset 0 to 4 -> page 1 (of Table1_hugerecords)
• offset 4 to 8 -> page 2 (of Table1_hugerecords)
• offset 8 to 14 -> page 3 (of Table1_hugerecords)
  ....

table Table1_hugerecords has a multi column PK ( byte[] serialized PK of Table1, int offset) and a single column (byte[] value)
in page1 of Table1_hugerecords
key1##offset0 -> "very"
key1##offset4 -> "huge"
key1##offset8 -> "hugerecord"

[diegosalvi]

Just some thought about this:

• pk field size should still be limited to avoid to load too much data in PK lookup and should apply a "record split" on pk too (at least for now)
• I'm not very positive to store page id on some record because pages can change (can really for huge records? mmm)

Thinking about again "huge" record pages could not change at all if we accept that: one page -> one record fragment. Cleanup e page compaction aren't needed in such case