Subject | RE: [Firebird-Architect] SMP - increasing single-query performance? |
---|---|
Author | Nigel Weeks |
Post date | 2006-11-09T00:18:34Z |
If a single query can be broken into multiple non-dependent operations, then
farmed out to seperate CPU's, then it might be possible...not an easy
exercise.
Otherwise, make sure you're using Classic Server, which will let your other
users carry on while the deep analytic queries are running...
N
-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Kirill S. Palagin
Sent: Thursday, 9 November 2006 6:38 AM
To: Firebird-Architect@yahoogroups.com
Subject: [Firebird-Architect] SMP - increasing single-query performance?
Hello.
Are there any plans to increase single-query performance by using more
than one CPU?
Rationalle behind this question - single-thread CPU performance not
increasing as it did earlier and heavy analitic queries are taking
longer and longer. Proliferation of multi-core CPUs allows cheap SMP and
offers way to speed up queries.
Regards,
K. Palagin.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
farmed out to seperate CPU's, then it might be possible...not an easy
exercise.
Otherwise, make sure you're using Classic Server, which will let your other
users carry on while the deep analytic queries are running...
N
-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Kirill S. Palagin
Sent: Thursday, 9 November 2006 6:38 AM
To: Firebird-Architect@yahoogroups.com
Subject: [Firebird-Architect] SMP - increasing single-query performance?
Hello.
Are there any plans to increase single-query performance by using more
than one CPU?
Rationalle behind this question - single-thread CPU performance not
increasing as it did earlier and heavy analitic queries are taking
longer and longer. Proliferation of multi-core CPUs allows cheap SMP and
offers way to speed up queries.
Regards,
K. Palagin.
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]