On Thu, May 22, 2014 at 1:33 AM, Lafras Henning
laf...@xietel.com[firebird-support]
firebird-support@yahoogroups.com wrote:
Hi Steve,
Do you think the performance gains were mostly due to the elimination of
the sub procedure, or mostly due the pure speed of the C functions?
During testing
Hi Tomas,
Understood the SP result set must be used as is, and that limits it as
an instrument for writing reusable code.
My idea behind the question is summarised in assumption 5.
To try an quantify this I have just finished a little test case doing 1M
operations as (100quries x 10K
Hi Steve,
Do you think the performance gains were mostly due to the elimination of
the sub procedure, or mostly due the pure speed of the C functions?
During testing did you ever run the UDF still from within the SP and if
so how was the performance increase?
In other words did the fact that
Thanks Thomas,
You make a good point about compile time SP optimisation becoming stale
as the data changes, but this can simply become a maintenance task,
along with monitoring of index efficiency, doing backups, and sweeping.
This should be a proviso to the assumptions.
But I stepped
Hi Lafras,
I'm sorry to not dig in that deep again, but your assumptions are
starting to get a bit complex.
Few thoughts:
- Not only sorting, but narrowing procedure result sets (where,
join, on) is not performed by indexed search.
- The main software architectural argument to write a stored
