...@mailinglists.sqlite.org] Im
Auftrag von Mitar
Gesendet: Donnerstag, 17. Oktober 2019 15:46
An: SQLite mailing list
Betreff: Re: [sqlite] [EXTERNAL] Re: Limit on number of columns in SQLite table
Hi!
Thanks for this input. So you are saying that sqlite3_column 100k times per row
is slow, but retrieving 100k rows
TERNAL] Re: Limit on number of columns in SQLite table
Hi!
Thanks for this input. So you are saying that sqlite3_column 100k times per row
is slow, but retrieving 100k rows to construct one "original" row will be
faster? So not sure if I understand why reading and decoding cells in ov
Hi!
Thanks for this input. So you are saying that sqlite3_column 100k
times per row is slow, but retrieving 100k rows to construct one
"original" row will be faster? So not sure if I understand why reading
and decoding cells in over multiple columns is so much slower than
reading and decoding
I have the impression that you still do not grasp the folly of a 100k column
schema.
See the example below, which only has 6 fields. As you can see, each field
requires a Column opcode and arguments (about 10 bytes) and a "register" to
hold the value (48 bytes), which for 100k columns uses
Hi!
In that case we would have to define a standard BLOB storage format,
slightly defeating the idea of using SQLite to define such standard
future-proof format. :-)
Mitar
On Thu, Oct 17, 2019 at 11:19 AM Hick Gunter wrote:
>
> Since your data is at least mostly opaque in the sense that
Since your data is at least mostly opaque in the sense that SQLite is not
expected to interpret the contents, why not split your data into "stuff you
want to query ins SQLite" and "stuff you want to just store"? The former means
individual columns, whereas the latter could be stored in a single
6 matches
Mail list logo
