On 6 February 2012 05:20, Dan Kennedy wrote:
> I think when two doclists are merged both are loaded into memory.
> Some types of queries load the entire doclist for a term into
> memory too.
Hmm, sounds like I definitely need to stick with rows representing
document pages
On 02/06/2012 05:54 AM, Hamish Allan wrote:
On 5 February 2012 21:20, Roger Binns wrote:
SQLite doesn't work on rows - it works on pages. A row will be contained
within one or more pages.
FWIW, I inspected the source for OP_Concat and found that it can
sometimes
On 5 February 2012 21:20, Roger Binns wrote:
> SQLite doesn't work on rows - it works on pages. A row will be contained
> within one or more pages.
FWIW, I inspected the source for OP_Concat and found that it can
sometimes avoid a memcpy (but presumably not if there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/12 12:09, Hamish Allan wrote:
> Sure, but a row can be re-written by copying each byte to memory and
> back out again,
SQLite doesn't work on rows - it works on pages. A row will be contained
within one or more pages.
> WRT premature
On 5 February 2012 19:11, Roger Binns wrote:
> The values for a row are stored sequentially. Changing the size of a
> value will at least require rewriting the row.
Sure, but a row can be re-written by copying each byte to memory and
back out again, or by copying the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/02/12 10:13, Hamish Allan wrote:
> 1) Is concatenation on UPDATE performed in-place?
The values for a row are stored sequentially. Changing the size of a
value will at least require rewriting the row.
I suggest reading the documentation on
1) Is concatenation on UPDATE performed in-place?
For example, with the following:
CREATE TABLE example (content TEXT);
INSERT INTO example(content) VALUES ('Hello, world!');
UPDATE example SET content = content || ' How are you?' WHERE rowid = 1;
Is the old value copied out to memory before
7 matches
Mail list logo