John Nagle animats.com> writes:
> "sqlite" has reasonably good SELECT performance on simple indices,
> but anything beyond that isn't all that great. Multiple processes
> updating the same sqlite database will have terrible performance,
> because the locking mechanism not only locks the entir
On 8/30/2010 12:00 PM, Benjamin Peterson wrote:
Denis Gomes gmail.com> writes:
Eventually my goal is to dynamically load and unload sections of a file based
database (could be tables or rows) in and out of memory for effeciency purposes.
Have you actually found this to be an useful optimiz
Yep, I see what you are saying. I am going to do a bit more research to see
how sqlite3 works internally, ie. cache size, page size, etc, and then
decide if I will need to mess with in-memory databases.
Thanks for your insight, appreciate it.
Denis
On Mon, Aug 30, 2010 at 3:51 PM, Benjamin Pete
Denis Gomes gmail.com> writes:
>
>
> Hey Benjamin,
>
> Take a look at this website I found about cached and in-memory databases. I
think the gist of the article is that caching is good if you are doing SELECTs
on data that is frequently used whereas in-memory speeds up writes, (inserts and
Hey Benjamin,
Take a look at this website I found about cached and in-memory databases.
I think the gist of the article is that caching is good if you are doing
SELECTs on data that is frequently used whereas in-memory speeds up
writes, (inserts and updates) to the db as well as querying. Maybe I
Denis Gomes gmail.com> writes:
>
> Eventually my goal is to dynamically load and unload sections of a file based
database (could be tables or rows) in and out of memory for effeciency purposes.
Have you actually found this to be an useful optimization? SQLite already
internally caches database
