On Aug 27, 2008, at 10:45 AM, Dennis Cote wrote:
> Hardy, Andrew wrote:
>>
>> Is there a performance hit assosiated with manifest typing?
>>
>
> I'm sure there is since sqlite must track the type of each data item
> as
> well as its value. But in reality this overhead is quite small.
>>
I was going to guess the opposite - that manifest typing reduces
overhead. (But as Dan pointed out - nobody will know until somebody
generates a version of SQLite that uses static typing and compares the
performance.)
The reason I think static typing would make things slower is that with
static typing, there has to be a bunch of checking during processing
to verify the specified datatype is in use. With the current database
file format, this checking must be done at query run-time. And there
is no savings in not having to track the types of each data item at
run-time because the current file format allows dynamic typing. So
any "strict affinity" mode would likely be slower than the current
SQLite.
If you designed a new file format that did not allow dynamic typing at
the file format layer, then you could perhaps do away with tracking of
types at query run-time. But if you go with a completely new file
format, you really wouldn't be dealing with SQLite any more. So I'm
not sure the comparison would be valid.
Note that if you really, really want to do static typing in SQLite you
can implement it using CHECK constraints:
CREATE TABLE ex(a INTEGER CHECK( typeof(a)='integer' ));
A "strict affinity" mode in SQLite would amount to adding these check
constraints automatically. If you look at it from this point of view,
it seems likely that strict affinity would slow down performance due
to the added cost of checking type constraints at each step.
D. Richard Hipp
[EMAIL PROTECTED]
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
