Hi Martin,
Le 08/11/2014 07:06, Martin Dobias a écrit :
> Hi Hugo
>
> On Tue, Nov 4, 2014 at 8:36 PM, Hugo Mercier
> wrote:
>>
>> * About indexes on virtual tables, contrary to what I wrote previously,
>> the xBestIndex() method of virtual tables should be enough to orient the
>> planner, an es
Hi Hugo
On Tue, Nov 4, 2014 at 8:36 PM, Hugo Mercier wrote:
>
> * About indexes on virtual tables, contrary to what I wrote previously,
> the xBestIndex() method of virtual tables should be enough to orient the
> planner, an estimated cost and estimated number of rows can be returned
> for each p
Hi,
Some additional information, after some more digging into sqlite code /
documentation / mailing lists:
* The parsing part of SQLite is private and cannot be requested by an
external program. Moreover, the parse phase directly builds a program,
not an abstract syntax tree. However, a formal gr
Hi Martin,
Thanks for your review.
Le 29/10/2014 17:34, Martin Dobias a écrit :
> Hi Hugo!
>
> On Tue, Oct 28, 2014 at 6:15 PM, Hugo Mercier
> wrote:
>> are there other opinions ?
>> Other arguments for one or the other side ?
>
>
> I have to say that initially I was very excited about the i
Hi Hugo!
On Tue, Oct 28, 2014 at 6:15 PM, Hugo Mercier wrote:
> are there other opinions ?
> Other arguments for one or the other side ?
I have to say that initially I was very excited about the idea... and
after thinking about the details I am getting less excited as there
are probably lots of
Hi Vincent
On 29.10.2014 10:51, Vincent Picavet wrote:
> Hello,
>
> Le mercredi 29 octobre 2014 08:34:11, Matthias Kuhn a écrit :
> [...]
>>> limitations. Only power users knowing what is really happening underneath
>>> will know what function to use, which is bad in UX terms.
>>> A comparison is
Hello,
Le mercredi 29 octobre 2014 08:34:11, Matthias Kuhn a écrit :
[...]
> > limitations. Only power users knowing what is really happening underneath
> > will know what function to use, which is bad in UX terms.
> > A comparison is OGR CSV driver versus CSV plugin... User has to know that
> > b
Hi Régis,
On 28.10.2014 17:35, Régis Haubourg wrote:
> Hi all,
> this is a very high level topic for me. I will just point out some
> user/funder needs, and maybe try to describe other strategies exist in GIS
> softs.
>
> As a user coming from both ESRI and Mapinfo world:
>
> - The main (and la
On 28.10.2014 16:30, Hugo Mercier wrote:
> Le 28/10/2014 13:21, Matthias Kuhn a écrit :
>> Hi Hugo
>>
>>> The optimization plan could be: don't try to optimize in the general
>>> case (premature optimization ...), only optimize specific
>>> well-identified cases.
>>> For now the only simple case I
Hi all,
this is a very high level topic for me. I will just point out some
user/funder needs, and maybe try to describe other strategies exist in GIS
softs.
As a user coming from both ESRI and Mapinfo world:
- The main (and last?) real advantage of MI was its native pseudo-SQL
capabilities (wi
Le 28/10/2014 13:21, Matthias Kuhn a écrit :
> Hi Hugo
>
>> The optimization plan could be: don't try to optimize in the general
>> case (premature optimization ...), only optimize specific
>> well-identified cases.
>> For now the only simple case I can see is when a join is done on tables
>> fro
Hi Hugo
On 28.10.2014 12:15, Hugo Mercier wrote:
> Hi Matthias,
>
> Le 28/10/2014 09:46, Matthias Kuhn a écrit :
>> Hi Hugo,
>>
>> Sorry for my slow response, I was quite busy the last days.
> With the 2.6 coming I know this is not the best time for this kind of
> discussion :( So thanks for your
Hi Matthias,
Le 28/10/2014 09:46, Matthias Kuhn a écrit :
> Hi Hugo,
>
> Sorry for my slow response, I was quite busy the last days.
With the 2.6 coming I know this is not the best time for this kind of
discussion :( So thanks for your time.
>
> I'll try to explain a bit more what I have in mi
Hi Hugo,
Sorry for my slow response, I was quite busy the last days.
I'll try to explain a bit more what I have in mind.
For example there is the new expression function "getFeature()" which is
an ad-hoc replacement for a join. I have been told that the performance
for rendering is not very g
Le 22/10/2014 11:21, Matthias Kuhn a écrit :
> On 22.10.2014 10:38, Hugo Mercier wrote:
>> Well, QgsExpression has been designed to mimick the SQL WHERE clause, so
>> yes I agree.
>> My point is that if you want to extend expression to support joins,
>> aggregates, window functions, etc. you end up
Moving this to a new thread (from 1:many relation...
On 22.10.2014 10:38, Hugo Mercier wrote:
> Well, QgsExpression has been designed to mimick the SQL WHERE clause, so
> yes I agree.
> My point is that if you want to extend expression to support joins,
> aggregates, window functions, etc. you end
16 matches
Mail list logo
