On Thu, 2018-04-12 at 13:00 -0600, Warren Young wrote:
> [EXTERNAL SOURCE]
>
>
>
> On Apr 12, 2018, at 11:14 AM, Jens Alfke wrote:
> >
> > I'm a Mac/iOS developer so I use the 'leaks' tool and Instruments app; I
> > don't know how this is done on Linux.
>
> Valgrind:
>
AFAICT the showmap program is just a pretty-printer for the /proc//smaps
file on android.
You need to compare three states:
1) before mmap() is called (there should be no section referring to your file)
2) after mmap() is called (the section should be there, but RSS=PSS=0)
3) after the loop
On 30/03/18 18:55, Igor Tandetnik wrote:
Row values support less-than comparison, so it kind of makes sense to
expect MIN to work on them, too.
That's what I was thinking too. One would expect aggregate MIN() and
MAX() to work over row values.
While we're on the subject of row values,
On 13/04/18 09:32, Mark Brand wrote:
On 30/03/18 18:55, Igor Tandetnik wrote:
Row values support less-than comparison, so it kind of makes sense to
expect MIN to work on them, too.
That's what I was thinking too. One would expect aggregate MIN() and
MAX() to work over row values.
While
I find I confused several concepts of memory. Sorry for that.
And I guess I finally understand what my question really is:
Still there is only one process doing a SELECT * in a 256M db file.
Then 256M physical memory should be used when doing the query. (Ignore the
cache_size.)
So the PSS of my
Hello,
thanks for the good documentation of the various database file formats. The wal
index one is a bit unclear to me in a few spots, maybe someone can help me out?
https://sqlite.org/walformat.html
2.1. The WAL-Index Header
there is a second copy of the WAL index information, but it's not
I can't do that (execute other statements) inside a sqlite3_preupdate_hook
callback.
On Fri, Apr 13, 2018 at 6:50 AM, Hick Gunter wrote:
> See pragma table_info;
>
> -Ursprüngliche Nachricht-
> Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
>
L.S.
Op vrijdag 13 april 2018 12:18:52 CEST schreef Frank van Vugt:
> Probably the unified headers in NDK are to blame as well, but:
> * when using ndk r16b to build sqlite for api-24 then the resulting library
> has __gnu_strerror_r unresolved
Oh, one addition: the toolchain used has been built
Just to be sure of the real issue:
- your application runs just fine with a small amount of memory (2M) for most
queries
- a small subset of queries requires "the whole db" to be kept in memory for
performance reasons
- the application should revert to "small memory" when the "whole db" query
Then do it when connecting to the database
-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im
Auftrag von João Ramos
Gesendet: Freitag, 13. April 2018 11:58
An: SQLite mailing list
Betreff: Re:
L.S.
Probably the unified headers in NDK are to blame as well, but:
* when using ndk r16b to build sqlite for api-22 then the resulting library
has no issues
* when using ndk r16b to build sqlite for api-24 then the resulting library
has __gnu_strerror_r unresolved
Relevant info on
It is normal in all modern operating systems for unused memory to be allocated
to buffer cache, so over time the "free" memory Is expected to go down unless
disk activity is near quiescent. Some operating systems will combine "cache"
and "free" memory to hide this from the casual user, but I
On 13 Apr 2018, at 8:40am, Mark Brand wrote:
> It also occurs to me that COUNT() should work (but doesn't) over sets of row
> values:
>
> sqlite> select count((1,2));
> Error: row value misused
>
> I would expect it to return the number of non-NULL row values in
On 13/04/18 14:12, Simon Slavin wrote:
On 13 Apr 2018, at 8:40am, Mark Brand wrote:
It also occurs to me that COUNT() should work (but doesn't) over sets of row
values:
sqlite> select count((1,2));
Error: row value misused
I would expect it to return the
14 matches
Mail list logo