[GRASS-dev] postgresql speed

[Wouter Boasson]

In reply to Vincent's remarks on database interfaces:
I don't know how the db.* modules are implemented, but I can't imagine that
they process the data themselves. That would mean downloading all the data
from PostgreSQL and building your own database engine...
When reading the grass manual: it states that all SQL of the DBMS is
available through the db.* modules, which means to me as much as: the SQL
Query/DDL string is passed to the DBMS engine, and the DBMS engine does the
job. I think they're correctly implemented and as fast as any other
interface to a RDBMS. Or maybe not when it comes to downloading data, but
the limiting factor is certainly to decide what data to download or update,
which is a geometry issue.
So, when operations where database access is involved are slow, it is very
likely that it is the code on top of the database access and management
(db.*) modules, which either doesn't make smart use of the database
capabilities, or geometry operations are involved.

With kind regards,
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 idea to
>use native dbms modules instead of db.*, e.g. if I program in perl, act
>on my data through DBI DBD::pg module.
>Vincent