_____________________________________________________________
> Od: "Simon Slavin" 
> Datum: 02.10.2011 14:01
>
>
>On 2 Oct 2011, at 12:49pm, Mira Suk wrote:
>
>> CREATE TABLE [Data1] (Index INTEGER PRIMARY KEY NOT NULL, Data BLOB, 
>> Description TEXT)
>> vs
>> CREATE TABLE [Data2] (Index INTEGER PRIMARY KEY NOT NULL, Description TEXT, 
>> Data BLOB)
>>  
>> essentially those tables are same. however accessing the column 
>> "Description" takes a lot longer in Data1 table (it's actually based on size 
>> of blob column)
>> did I hit some implementation detail (aka all columns data are read till the 
>> one required is returned) ?
>
>I will let the experts handle this.  I do know that if you have either TEXT or 
>BLOB columns with a lot of data in you never do a 'SELECT *' unless you really 
>need it.
 
this is not about select *
simpliest test case is SELECT DISTINCT "Description" FROM "Data?" - distinct 
just to force sqlite to process all data before returning.

>> should I actually reorder columns based on expected data / size for SQLite ?
>
>If there is behaviour like the above, then your ordering should not be based 
>on data/size.  It would be more useful to base it on how often you expected to 
>access each column.  So for example, if you display tables showing 
>[Description] a lot, but >rarely need the [Data], then it might be fastest to 
>put [Description] in first.
 
you're correct. the "how often" factor should play main role. however putting 
integer/double field after blob just because it's less used would not be smart 
too, same IMHO goes for VARCHAR(N) where N is expected small, that is much 
smaller than database pagesize.
 
 
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to