>From: D. Richard Hipp [mailto:[EMAIL PROTECTED]
>
-- snip --
>simplifies to O(logN) which is clearly less than O(N).
>In that case, it pays to use the index.
Which is my case I believe, thanks. It's been years (OMG, 16!) since I
had an algorithms class. Is that log base 2, or does it
At 5:05 PM -0700 6/21/04, Keith Herold wrote:
> down the result set would make things faster..? Wouldn't the select
here:
CREATE TABLE tmp ( flag boolean, name text );
SELECT name FROM tmp WHERE flag = 1 AND name LIKE '%foo%';
run faster with an index on the flag column since it can
> On Jun 20, 2004, at 9:07 PM, Darren Duncan wrote:
> down the result set would make things faster..? Wouldn't the select
> here:
>
>CREATE TABLE tmp ( flag boolean, name text );
>
>SELECT name FROM tmp WHERE flag = 1 AND name LIKE '%foo%';
>
> run faster with an index on the flag
On Jun 20, 2004, at 9:07 PM, Darren Duncan wrote:
Generally speaking, you should only use indexes on table columns that
have a lot of distinct values, and each one only appears a few times.
You should not use indexes on columns that have few distinct values
and each appears many times; in the
At 5:23 PM -0500 6/21/04, Tim wrote:
It sounds like SQLite 3.0 only supports one text representation per
database ("Internally and in the disk file, the same text
representation is used everywhere."). Is there a particular reason
for this limitation? What if I want to store one column as UTF8
Tim wrote:
> It sounds like SQLite 3.0 only supports one text representation per database
> ("Internally and in the disk file, the same text representation is used
> everywhere."). Is there a particular reason for this limitation?
The reason is to keep the API simple. If the programmer selects a
It sounds like SQLite 3.0 only supports one text representation per database
("Internally and in the disk
file, the same text representation is used everywhere."). Is there a particular
reason for this
limitation? What if I want to store one column as UTF8 text and another column as
UTF16?
Hi
having recently started playing with sqlite and I am very impressed. As my
primary interest is to use it with Tcl, I'm wondering if a pre-compiled
tclsqlite.dll can be made available for release 3.0 .
I also notice that the tclsqlite.dll for 2.8.14 appears to have dissapeared
from the
Doug Currie wrote:
The TEMP_STORE features should have been fully implemented by
check-in [1302] on 2004-Apr-23. Have you observed otherwise?
1. Searching for TEMP_STORE in the sources, I see it described in the
comments in main.c but it does not appear to be used anywhere in the
code. So, this
Doug Currie wrote:
> I have not modified the sqlite sources to implement the TEMP_STORE features.
>
The TEMP_STORE features should have been fully implemented by
check-in [1302] on 2004-Apr-23. Have you observed otherwise?
--
D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
Replying to my own message...
I bit the bullet and installed autoconf under msys/mingw. Using this
tool I updated configure.ac and Makefile.in to address some of the
build issues identified below -- everything but the OMIT macros. Of
course, I have not modified the sqlite sources to implement the
Hello everybody,
Should I set 'PRAGMA full_column_names = OFF' every time I execute a
SELECT statement, or just once, right after I open the database? What
is the lifetime of this setting?
Thanks,
-- Tito
The argument is a "pointer to function returning void and taking void*
as its argument" (like "free");
Here's a sample program:
#include
void func(void (*)(void*));
void freemystuff(void* in);
int main(int argc, char* argv[])
{
It would be even better if SQLite could do a better
job at optimizing the index searches.
__
Raymond Irving
--- rene <[EMAIL PROTECTED]> wrote:
> Hi,
>
> i ran into a simulair case as this message
>
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01646.html
>
> where an index actually slows
14 matches
Mail list logo
