Scribit Robert L. Read dies 11/04/2007 hora 09:01:
> The real problem here is that Elephant is so different, and so much
> more powerful and convenient than a relational system, that [...] if
> we use a relational benchmark, we are tying our hands behind our back.
We could also look at OO specific
I suspect the raw IO costs are going to dominate the query compilation
time, and for straight scans and point reads, which I imagine to be the
majority of the queries, the optimizers will find a good plan trivially.
An interesting experiment would be to take a simple benchmark that
stores a million
It's interesting that there is only a little performance advantage.
Have you done some profiling to see where the time is going? It
sounds like either the queries were simple enough that the
compilation step was trivial or that we're seeing Ahmdal's law and
the SQL costs are swamped by so
Regarding stored procedures, I agree with Ian that the main performance
advantage that come from them is that the query planning is prepared in
advance. This is also done if you use prepared sql statements, so they
give the same advantage. Stored procedures can however be faster if they
involve sev
Scribit Robert L. Read dies 03/04/2007 hora 11:08:
> Stored procedures tend to not be very portable; therefore to put them
> in the current "postgres" backend, which should really be called a
> "clsql" backend, would make it less likely to work with MySQL.
I was thinking at having some PostgreSQL-
As I mentioned to Ian separately, my priority is integrating the
"postmodern" backend over modifying the Postgres back end, as this may
very well be a much superior backend in terms of performance, and easily
usable by anyone using Postgres now.
Stored procedures tend to not be very portable; ther
Do you mean stored between sessions, stored in-memory between uses,
or stored on the DB to avoid sending queries back and forth? My
understanding is that Tthe expense of a SQL query is not so much in
the parsing as it is in forming a query plan to execute. The server
stores query plans, b
Recently, a discussion started in the Torque project, an ODB for Java
that also provides persistence, about the possible use of stored
procedures instead of building SQL requests, because for frequent cheap
operations, the overhead of parsing and executing SQL can be
non-trivial.
Do you think such
