https://twitter.com/john_lam/status/593837681945092096
--
D. Richard Hipp
drh at sqlite.org
> (2) Even if the row is all on one page, SQLite has to compute sizes of
> all prior columns and add those sizes together in order to find the
> offset to a particular column in that row. The fewer prior columns
> there are, the less work is involved for this step.
I?m curious: how much work are w
On 04/30/2015 02:08 PM, Dominique Pell? wrote:
> Dan Kennedy wrote:
>
>> On 04/30/2015 07:41 AM, Scott Robison wrote:
>>>
>>> I wrote up some test code today that definitely forces a SQLITE_NOMEM
>>> condition, and there are no leaks (though there are a couple really large
>>> outstanding allocati
I noticed that the sqlite documentation does not show the
CONSTRAINT keyword, but it looks as though sqlite accepts the
keyword. Also it appears that sqlite does not support DROP
CONSTRAINT, but does support DROP VIEW and other similar.
Is this correct?
--
Scott Doctor
scott at
Congratulations.
On Thu, Apr 30, 2015 at 8:24 PM, Richard Hipp wrote:
> https://twitter.com/john_lam/status/593837681945092096
>
> --
> D. Richard Hipp
> drh at sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> ht
On 30 Apr 2015, at 6:16pm, Drago, William @ CSG - NARDA-MITEQ wrote:
> Read Mr. Hipp's reply to me when I asked a similar question:
To rephrase (1) slightly, when reading a row from a table, SQLite reads up to
the last column asked for and no further. So if you have columns you rarely
need t
Read Mr. Hipp's reply to me when I asked a similar question:
"Two things to be aware of:
(1) When reading a row, SQLite reads from beginning to end. So if you have
some small integer or boolean fields, it is better to put them first in the
table. Otherwise, SQLite has to read past the big BLOBs
On 4/30/15, James K. Lowden wrote:
>
> SQLite keeps its rows in pages and reads whole pages. Within a page it
> references rows and columns by offset. Every location within a page is
> accessed in constant time. So column order doesn't matter because
> page-offset doesn't matter.
>
It's more c
On Thu, 30 Apr 2015 09:45:14 -0700
Pol-Online wrote:
> I wasn?t able to find the answer to this question online: does the
> column order matter for SQLite performance? E.g. should you put fixed
> width columns like INTEGER before TEXT or BLOB?
I'm going to check that box as No.
SQLite keeps
On Wed, 29 Apr 2015 20:29:07 -0600
Scott Robison wrote:
> > That code can fail on a system configured to overcommit memory. By
> > that standard, the pointer is invalid.
> >
>
> Accidentally sent before I was finished. In any case, by "invalid
> pointer" I did not mean to imply "it returns a bit
On 04/30/2015 07:41 AM, Scott Robison wrote:
>
> I wrote up some test code today that definitely forces a SQLITE_NOMEM
> condition, and there are no leaks (though there are a couple really large
> outstanding allocations to force an error without needing to insert
> gigabytes of data).
>
> In think
On Thu, Apr 30, 2015 at 11:42 AM, James K. Lowden
wrote:
> On Wed, 29 Apr 2015 20:29:07 -0600
> Scott Robison wrote:
>
> > > That code can fail on a system configured to overcommit memory. By
> > > that standard, the pointer is invalid.
> > >
> >
> > Accidentally sent before I was finished. In a
On Fri, 3 Apr 2015 18:16:18 +0300
Artem wrote:
> Hi!
>
> The situation is like that. There?s a SQLite database with around 3
> billion records. Each record consists of a certain CHAR field and
> several other additional fields with different types. The file size
> is approx. 340 gb. The maximum
This makes my head spin. ridiculous that an over commit even exists. any
slight performance gain is totally nullified by a crashing program.
-
Scott Doctor
scott at scottdoctor.com
-
On 4/30/2015 11:47 AM, Scott Robison wrote:
> On Thu, Apr 30, 2015 at 11
On Apr 29, 2015 11:50 PM, "Dan Kennedy" wrote:
>
> On 04/30/2015 07:41 AM, Scott Robison wrote:
>>
>>
>> I wrote up some test code today that definitely forces a SQLITE_NOMEM
>> condition, and there are no leaks (though there are a couple really large
>> outstanding allocations to force an error w
On Thu, Apr 30, 2015 at 2:52 AM, James K. Lowden
wrote:
> On Tue, 28 Apr 2015 09:24:56 +0200 Dominique Devienne
> wrote:
> > On Tue, Apr 28, 2015 at 4:16 AM, James K. Lowden <
> jklowden at schemamania.org> wrote:
> > > A major hurdle is the memory model: because array-programming
> > > librarie
Hi,
It seems that the built-in tokenizers (or at least the unicode61 one) has no
lower-limit regarding the number of characters in a token. For instance looking
for records containing `t` will return the ones with sentences containing
?don?t?.
Does this mean FTS is indexing all the ?I? and ?a?
Hi,
I wasn?t able to find the answer to this question online: does the column order
matter for SQLite performance? E.g. should you put fixed width columns like
INTEGER before TEXT or BLOB?
-Pol
Pol-Online
info at pol-online.net (mailto:info at pol-online.net
Dan Kennedy wrote:
> On 04/30/2015 07:41 AM, Scott Robison wrote:
>>
>>
>> I wrote up some test code today that definitely forces a SQLITE_NOMEM
>> condition, and there are no leaks (though there are a couple really large
>> outstanding allocations to force an error without needing to insert
>> g
19 matches
Mail list logo
