On 15/09/12 17:03, Simon Slavin wrote:

On 15 Sep 2012, at 12:08pm, Elefterios Stamatogiannakis <est...@gmail.com> 
wrote:

What i would really like to have in SQLite concerning OLAP, would be bigger 
pages,

You can set pagesize for a new database using a PRAGMA:

<http://www.sqlite.org/pragma.html#pragma_page_size>

The maximum allowed pagesize is 65536 bytes.  Create a new database file, then 
issue the PRAGMA before any CREATE commands.  If you have an existing database 
and want to change it you have to export the data, make a new database and 
import the data again, but this can all be done in two commands to the shell 
tool.


Yes i know about the page size pragma and i actively use it. What i meant to say was that i would like to have even bigger pages than what is currently possible.

and internal page compression in a similar manner that column stores do [^]. 
This would greatly alleviate the storage pain of using denormalized DBs which 
is a must for OLAP.

This feature would indeed be suitable for a server-client database engine 
designed to run on multipurpose computers.  But SQLite is designed more in 
embedded machines in a single-processor environment.  For example, my TV 
recorder uses it to list the TV channels and meta-data about its recordings, 
and I have an extremely low-power GPS device which uses it for Positions of 
Interest.  The fact that SQLite turns out to be so useful as an embedded DBMS 
inside, for example, a web browser is just a bonus.  As the documentation says, 
if you need network-savvy client-server stuff, look elsewhere.


Could you explain why you think that compressed pages are suitable for a client-server database engine and not for an embedded one ? Because i don't see why.

From my point of view, being able to have even smaller databases than now, without any major overhead would be most useful for embedded purposes where disk and memory (pages could be kept compressed in the cache) space are at a premium.

Also considering that the compression i proposed doesn't have anything at all to do with using a block compressor on a page, but it concerns the way that the rows are stored in a page, there won't be any noticeable CPU usage increase.

l.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to