Hello!
The problem is only with virtual tables. With ordinary tables "IN (...)" work
fine:
sqlite> explain query plan select count(*) from data_content where rowid in (1);
0|0|TABLE data_content USING PRIMARY KEY
CPU Time: user 0.004000 sys 0.00
sqlite> select count(*) from data_content whe
IN( {inlist} ) syntax is not optimized, Alexey.
http://www.mail-archive.com/sqlite-users@sqlite.org/msg49985.html
Regards
Tim Romano
On Mon, Apr 5, 2010 at 3:22 PM, Alexey Pechnikov wrote:
> Hello!
>
> On Monday 05 April 2010 22:22:40 Roger Binns wrote:
> > Virtual tables already let you imple
Hello!
On Tuesday 06 April 2010 00:16:32 Roger Binns wrote:
> I'd recommend just going ahead and implementing a prototype using the
> virtual table API. That would at least allow you to substantiate any
> requests for a different/changed API.
Well, it's good for prototype.
Best regards, Alexe
On 04/05/2010 12:22 PM, Alexey Pechnikov wrote:
> Now virtual tables performance is bad in some useful situations. As example
> this query produce full-scan of the FTS3 virtual table 'data':
I don't see what FTS3 has to do with your hash indices, nor do I see
requirements to implement things the
Hello!
On Monday 05 April 2010 22:22:40 Roger Binns wrote:
> Virtual tables already let you implement indices in any way you want - see
> the xBestIndex and xFilter methods. (The former is especially hard to
> understand until you have worked with it a bit.)
Now virtual tables performance is b
On 04/05/2010 10:23 AM, Alexey Pechnikov wrote:
> May be a new interface for "virtual indices" will be best solution. But it
> can be realised as virtual table too. Or in SQLite core engine of cource.
Virtual tables already let you implement indices in any way you want - see
the xBestIndex and xF
Hello!
On Monday 05 April 2010 19:48:06 you wrote:
> On Monday 05 April 2010 18:11:40 Roger Binns wrote:
> > Wouldn't it require changing the file format?
>
> It's not required. The FTS3 extension works with current file format
> and rtree extension too.
May be a new interface for "virtual indic
Yes. I think a couple of hash choices would be a good addition to SQLite.
I posted recently asking about INTERSECT and whether a "minimal perfect
hash" might be worth consideration for that function.
http://www.mail-archive.com/sqlite-users@sqlite.org/msg51046.html
And a standard sparse hash wou
Hello!
On Monday 05 April 2010 18:11:40 Roger Binns wrote:
> Wouldn't it require changing the file format?
It's not required. The FTS3 extension works with current file format
and rtree extension too.
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
_
Yep. A big change...
Artur :3
-
Am 05.04.2010, 16:11 Uhr, schrieb Roger Binns :
> On 04/05/2010 05:45 AM, Alexey Pechnikov wrote:
>> Is anyone interested in this feature?
>
> Wouldn't it require changing the file format?
>
> Roger
> ___
>
On 04/05/2010 05:45 AM, Alexey Pechnikov wrote:
> Is anyone interested in this feature?
Wouldn't it require changing the file format?
Roger
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-user
Hello!
On Monday 05 April 2010 16:47:48 Simon Slavin wrote:
> Do you have an idea when a tree index should be used, and when a hash index
> should be used ? Will you use both all the time, or allow the user to select
> which one to use ?
See tests here:
http://geomapx.blogspot.com/2010/04/sqli
On 5 Apr 2010, at 1:45pm, Alexey Pechnikov wrote:
> The b-tree index is not good choice for high-selective data, but there is no
> hash index in SQLite. The hash index will be useful for many new projects
> and will optimize a lot of existing applications.
>
> Is anyone interested in this featu
Hello!
The b-tree index is not good choice for high-selective data, but there is no
hash index in SQLite. The hash index will be useful for many new projects
and will optimize a lot of existing applications.
Is anyone interested in this feature?
Best regards, Alexey Pechnikov.
http://pechnikov.
14 matches
Mail list logo
