Even Rouault mines-paris.org> writes:
>
> Jukka,
>
> I tried to simulate your scenario but couldn't observe any performance
> difference (on Linux, but I doubt that the OS would make a difference) when
> generating a test DB with 3.7.9 or 3.7.14, and using it with the other
> version.
> Howe
Jukka,
I tried to simulate your scenario but couldn't observe any performance
difference (on Linux, but I doubt that the OS would make a difference) when
generating a test DB with 3.7.9 or 3.7.14, and using it with the other
version.
However it might heavily depend on the number of records that
lqt.it> writes:
>
> On Mon, 9 Jun 2014 07:31:05 + (UTC), Jukka Rahkonen wrote:
> > Perhaps this has something to do with different SQLite versions
> > included in
> > GDAL and Spatialite-gui. My GDAL is v.2.0 Win-64 build from
> > gisinternals.
> >
> > This kind of behaviour is nasty when
On Mon, 9 Jun 2014 07:31:05 + (UTC), Jukka Rahkonen wrote:
Perhaps this has something to do with different SQLite versions
included in
GDAL and Spatialite-gui. My GDAL is v.2.0 Win-64 build from
gisinternals.
This kind of behaviour is nasty when planning to build well optimized
and
index
Hi,
This should hopefully be pretty much independant of GDAL itself, but rather
tied to the sqlite version used.
I can see that gisinternals builds use sqlite 3.7.9. In the news of version
3.7.14 I read "And the query planner has been enhanced to better use covering
indices on queries that use
Hi,
I have a table with 1.2 million rows. Attribute 1 has 320 distinct values
(text). Attribute 2 is numeric (area).
My test query is this:
select * from table
where attr_1='009'
or area>1000;
First index makes query a bit faster
ogrinfo test.gpkg -sql "create index test_attr_1_idx on test (att