Wouter wrote:
> However, in the current implementation of some Grass tools it seems to me
> (correct me if I'm wrong) that there are a few operations where the
> database is certainly the limiting factor. The most notable example is
> renaming a large vector table, which is extremely slow. I notic
On 27/02/09 14:19, Markus Metz wrote:
Moritz Lennert wrote:
Yes, querying the geometries is very slow currently because of the
fact that the spatial and topological index is kept in memory and not
on file, so every time you launch an interactive query, it has to
rebuild it which is very slow
Moritz Lennert wrote:
Yes, querying the geometries is very slow currently because of the
fact that the spatial and topological index is kept in memory and not
on file, so every time you launch an interactive query, it has to
rebuild it which is very slow on large vectors. See
http://josef.fs
On 26/02/09 18:37, Wouter Boasson wrote:
In response to:
Hello,
reading this thread, and being sometimes concerned with large vector
files (associated with big related tables), I wonder if it's worth
manually creating indexes (on cat field) : can it be a effective way to
speed up queries, or is
Thank you Moritz and Wouter,
personnaly used to operating directly on tables through a psql terminal,
I am not aware of the actual performances of db.* modules.
In the present case, programming special interfaces for end-users who
massively implement vector attributes, maybe it would be a good id
In response to:
>Hello,
>reading this thread, and being sometimes concerned with large vector
>files (associated with big related tables), I wonder if it's worth
>manually creating indexes (on cat field) : can it be a effective way to
>speed up queries, or is the kink elsewhere, at the geometric l
