Re: [sqlite] Convert data to binary
On 11/26/2011 05:02 AM, Nico Williams wrote: You can CAST TEXT to BLOB, and you can use x'' for literal BLOBs. You can. The result of which is a blob that corresponds to either the utf-8 or utf-16 (big or little endian) encoding of the text, depending on the encoding used by the database file. FWIW. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite support for geometric column types?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/11/11 20:34, Senthil_25 wrote: > Just want to know whether sqlite support for gemotric column types? The Rtree extension distributed with SQLite will likely meet your needs: http://www.sqlite.org/rtree.html Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7Qb3MACgkQmOOfHg372QQ0RACdHVvW7XDuiQvb6oiItHsFvtIJ CtsAoOHP85oyovjm/Zxo+N+CRqhMLJ87 =oGxz -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite support for geometric column types?
Hi, I am new to sqlite. Just want to know whether sqlite support for gemotric column types? Please Help me... -- View this message in context: http://old.nabble.com/sqlite-support-for-geometric-column-types--tp32876624p32876624.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] [sqlite TOO slow
On Thu, Nov 24, 2011 at 05:22:38PM +, Simon Slavin scratched on the wall: > On 24 Nov 2011, at 5:10pm, Jay A. Kreibich wrote: > > On Thu, Nov 24, 2011 at 08:08:12AM +, Simon Slavin scratched on the > > wall: > > > >> It is faster to search integers than it is to search real numbers. > > > > Why? Both types are a string of 64 bits. Both types use the same > > integer-based logic for the =, <, and > operations. > > > > The only real difference is that integers are stored in a compressed > > format. While that means they have a higher CPU cost to decode, the > > smaller size likely makes up for the encoding overhead with improved > > I/O times. I'm not sure there is a strong practical win, however-- > > especially if the data is in cache, or doesn't span several pages. > > Hmm. I really should check this out with SQLite. It is generally > true in computing. FP mathematics instructions (such as + - * / ) typically take many more CPU cycles to complete than their integer equivalents. However, when it comes to comparisons (such as = < <= >= > ) you might use in an index scan, the IEEE 754 standard is specifically designed so that these operations can be done with the exact same logic as unsigned integer numbers. In most CPUs the floating-point pipeline has its own logic units to perform these operations (due to the separation of integer and FP registers), but the speed of these logic units should be the same as the primary integer units. > It may not be true given how SQLite uses different > numbers of bytes to store different sized integers. Yes-- the variable length integers means there are extra decoding steps for the integers. However, the variable length also means one can, in theory, stuff more "typical" integer values into the same database page, saving on I/O. If the I/O is from disk, this reduced I/O cost, as small as it is likely to be, is still likely to save significantly more than the integer decoding costs. I/O is just that expensive next to processor cycles. That's my guess, anyways. I'm not sure things would be so clear if you were working out of the OS file system cache. Overall, you might be right... But if there is a difference, it is likely related to the variable length nature of integers, not something inherent in FP math being more expensive than integer math. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Convert data to binary
You can CAST TEXT to BLOB, and you can use x'' for literal BLOBs. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Convert data to binary
I'd like to store any data as binary in my sqlite database, I approached
the problem by trying to hex() the input because the x' ' operator accepts
hex and outputs binary, for example:
x'hex("hello world")'
but that syntax doesn't work, is there any way to make storing any data as
its binary value possible?
--
Carl
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Difference between FUNCTION(X)>='Y' and FUNCTION(X)>=FUNCTION('Y')
Thanks for the tip for doing hex() on the results.
My function wasn't returning what I expected due to sqlite3_result_text16
taking bytes not characters.
it now works fine.
Soundfaction wrote:
>
> I have a situation where I get different results for this:
>
> select ... where FUNCTION(X)>='Y'
>
> vs
>
> select ... where FUNCTION(X)>=FUNCTION('Y')
>
> And FUNCTION('Y') == 'Y' so I thought there should be no difference
> between the two queries.
>
> For some reason in the latter case it behaves as:
>
> select ... where FUNCTION(x)>'Y'
>
> This is SQLITE version 3.7.3 as we are still having performance issues
> with 3.7.9
>
> In this specific case FUNCTION(x) just skips some characters at the start
> of the string X and returns an alloc'ed string of the rest. e.g
>
> FUNCTION('RE: this') produces 'this'
>
--
View this message in context:
http://old.nabble.com/Difference-between-FUNCTION%28X%29%3E%3D%27Y%27-and-FUNCTION%28X%29%3E%3DFUNCTION%28%27Y%27%29-tp32875942p32876040.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
