On Fri, Mar 4, 2016 at 4:45 PM, Eric Grange wrote:
> [...] why can't we both have our cake and eat it? :)
>
Exactly. That's why I've been asking/advocating for out-of-row (large)
blobs for a while now.
See for example
http://permalink.gmane.org/gmane.comp.db.sqlite.general/97686. --DD
Thanks for all the details!
I was already storing the really large blobs in their own tables.
However I will have to review the situations for smallish blobs (about as
large as the rest of the fields in a record), as moving them to another
table would halve the number of pages involved for
I haven't seen any anyone else mention this yet. Another consideration when
working with large blobs is to make those columns that last ones in your
schema. To quote Dr. Hipp:
"make the BLOB columns the last column in your tables. Or even store the BLOBs
in a separate table which only has two
> All BLOBs are stored inline. The only complication comes when the total
row length is longer than a page.
Ok thanks!
That is besides my original question but what is the complication in that
case?
Is the blob partially stored in the row, or is some indirection to other
pages used, with only
What is the likely max length of a row in your table? if your row
length is less than page length-35 then it will fit in to one page.
The amount of wasted page depends on what fraction of a page size your
typical record is.
If you have a record that is 600 bytes long on a DB with 1024 byte
page
> On 3 Mar 2016, at 8:16am, Eric Grange wrote:
>
>> All BLOBs are stored inline. The only complication comes when the total
>> row length is longer than a page.
>
> Ok thanks!
>
> That is besides my original question but what is the complication in that
> case?
> Is the blob partially stored
On 2016/03/02 6:47 PM, Eric Grange wrote:
> Hi,
>
> I am wondering if very small BLOBs are stored inline with the record fields
> (in the same page) or in another page?
>
> So far I had not worried about it, but now I have a usage case where I need
> to store 128 and 256 bit integers (numbers,
Hi,
I am wondering if very small BLOBs are stored inline with the record fields
(in the same page) or in another page?
So far I had not worried about it, but now I have a usage case where I need
to store 128 and 256 bit integers (numbers, not IDs or hashes), SQLite does
not support such large
On Wed, Mar 2, 2016 at 4:42 PM, R Smith wrote:
>
>
> Personally, unless your space is constrained, I would simply save the
> numbers as strings, perhaps Hex or BCD with leading chars and convert as
> needed. This would sort correctly without tricks and not do much worse for
> space. (Base64 would
On 2 Mar 2016, at 4:47pm, Eric Grange wrote:
> I am wondering if very small BLOBs are stored inline with the record fields
> (in the same page) or in another page?
All BLOBs are stored inline. The only complication comes when the total row
length is longer than a page.
Simon.
On 3/2/16, Eric Grange wrote:
> I am planning to store them as
> little-endian binary blobs, so that the BINARY collation can work for
> sorting,
Surely you mean big-endian?
--
D. Richard Hipp
drh at sqlite.org
11 matches
Mail list logo