On 14/09/12 22:56, Clemens Ladisch wrote:
Elefterios Stamatogiannakis wrote:
On 13/09/12 23:02, Clemens Ladisch wrote:
For my main workload (OLAP) this can make an enormous difference!
OLAP isn't quite the typical SQLite use case. But do you have any
numbers (which would help deciding
On 14/09/12 22:56, Clemens Ladisch wrote:
But do you have any numbers (which would help deciding whether to accept this
patch)?
I've run two queries on two different DBs:
- DB1: Size 414M, Count of recs 2999671, the table has 17 Cols
- DB2: Size 1.4G, Count of recs 1975986, the table has
On 15 Sep 2012, at 12:08pm, Elefterios Stamatogiannakis est...@gmail.com
wrote:
What i would really like to have in SQLite concerning OLAP, would be bigger
pages,
You can set pagesize for a new database using a PRAGMA:
http://www.sqlite.org/pragma.html#pragma_page_size
The maximum allowed
On Fri, Sep 14, 2012 at 5:24 PM, Roger Binns rog...@rogerbinns.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a chance that the change will go into SQLite mainline?
Not without a copyright release.
And it may require more especially if you are an employee. See the
Simon Slavin wrote:
On 15 Sep 2012, at 12:08pm, Elefterios Stamatogiannakis est...@gmail.com
wrote:
What i would really like to have in SQLite concerning OLAP, would be bigger
pages,
You can set pagesize for a new database using a PRAGMA:
On 15/09/12 17:03, Simon Slavin wrote:
On 15 Sep 2012, at 12:08pm, Elefterios Stamatogiannakis est...@gmail.com
wrote:
What i would really like to have in SQLite concerning OLAP, would be bigger
pages,
You can set pagesize for a new database using a PRAGMA:
I have a question.
Will the covering index scan optimization also cover the automatically
created indexes?
So lets say that for a certain part of a query, the optimizer decides to
create an automatic index. Will the same index be chosen for doing a
scan (instead of a full table scan) for
A more complete implementation of fullscan-by-covering-index can be seen
here:
http://www.sqlite.org/src/info/cfaa7bc128
Many of the changes were the addition of an ORDER BY rowid clause to test
queries in the test suite. For the previous 12 years, SQLite has always
returned content in rowid
On 15/09/12 21:57, Richard Hipp wrote:
So my thinking now is that this optimization should not be merged to trunk
unless it is first disabled by default and only enabled by a compile-time
or start-time option.
IMHO, a pragma that enables/disables it persistently on a DB would be ideal.
Many
On 15 Sep 2012, at 7:57pm, Richard Hipp d...@sqlite.org wrote:
So my thinking now is that this optimization should not be merged to trunk
unless it is first disabled by default and only enabled by a compile-time
or start-time option.
How about for SQLite4 ?
Simon.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/09/12 11:57, Richard Hipp wrote:
... and that this change merely exposes their brokenness. I won't
dispute that. Nevertheless, with this changes, those applications will
stop working.
There is the lint mode request:
On 16 Sep 2012, at 2:16am, Roger Binns rog...@rogerbinns.com wrote:
It would be *really* helpful if there was some way to put SQLite into a
mode by which developers using it can test and improve their own apps. If
their app worked in that lint/test mode they would know that the chances
of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/09/12 18:23, Simon Slavin wrote:
PRAGMA lint_mode=ON
I'm sure there is some ideal to preserve the Lite part of the name and a
lint mode would be quite intrusive. I can imagine a separate compilation
mode (eg another #define), or some
Elefterios Stamatogiannakis wrote:
On 13/09/12 23:02, Clemens Ladisch wrote:
Eleytherios Stamatogiannakis wrote:
Is there a reason for SQLite to not use a covering index for scans?
The query optimizer does not allow indexes that are not needed for some
DISTINCT, WHERE, or ORDER BY clause:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Is there a chance that the change will go into SQLite mainline?
Not without a copyright release.
And it may require more especially if you are an employee. See the bottom
section of http://www.sqlite.org/copyright.html
And of course it is more
Eleytherios Stamatogiannakis wrote:
create table t (c1,c2, c3, c4);
create index idxtc1 on t(c1);
explain query plan select c1 from t;
SCAN TABLE t (~100 rows)
explain query plan select c1 from t order by c1;
SCAN TABLE t USING COVERING INDEX idxtc1 (~100 rows)
It
On 13/09/12 23:02, Clemens Ladisch wrote:
Eleytherios Stamatogiannakis wrote:
It seems to me that using a covering index scan would always be faster
in both cases (fewer disk page reads).
Yes, if the index has fewer columns than the table.
In my experience, the most frequent case is for an
Hello,
I've just wanted to ask about using covering indexes for scans. A very
rudimentary test:
create table t (c1,c2, c3, c4);
create index idxtc1 on t(c1);
The simple select scans the full table:
explain query plan select c1 from t;
SCAN TABLE t (~100 rows)
A select with a
18 matches
Mail list logo