Hi!
For a long time I have been using LEFT JOINs rather than JOINs
everywhere, because of some past experience with Firebird 1.5 that LEFT
JOIN is much faster than JOIN, even if I have to use WHERE
key_of_the_joined_table IS NULL afterwards. Today I encountered a case
where this is the case even
Hi all,
Can someone let me know if the following is thread-safe:
- a client library from Firebird version 1, 1.5, 2 or 2.1
- using a connection per thread
- executing calls via multiple threads
With regards,
Martijn Tonies
Upscene Productions
http://www.upscene.com
Download Database
--- In firebird-support@yahoogroups.com, Martijn Tonies wrote:
Hi all,
Can someone let me know if the following is thread-safe:
- a client library from Firebird version 1, 1.5, 2 or 2.1
- using a connection per thread
- executing calls via multiple threads
Add also: protect
Hi Vlad,
Can someone let me know if the following is thread-safe:
- a client library from Firebird version 1, 1.5, 2 or 2.1
- using a connection per thread
- executing calls via multiple threads
Add also: protect attach\detach calls with common mutex.
You mean that connect/disconnect
whether the computed field affect the performance and speed of the table?
simple example :
table x
value1 integer
value2 integer
total computed(value1+value2)
table y
value1 integer
value2 integer
query1
select * from x
select total from x
query2
select * from y
select value1+value2 as
Hello Josef,
I've never had that issue using Firebird, but some time ago I had a similar
behavior with SQL Server and the responsible was a fragmented index. May be you
should take a look to your indexes design or rebuild them via backup/restore.
Regards,
Hello Josef,
I've never had that issue using Firebird, but some time ago I had a
similar behavior with SQL Server and the responsible was a fragmented
index. May be you should take a look to your indexes design or rebuild
them via backup/restore.
Hi!
That should not be the case here, as
but LEFT JOIN is diferente of JOIN...
- LEFT JOIN brings all the data filtered from the FROM table, and
- JOIN brings only the data that have the ON condition in the JOINED table.
Att,
Alexis Diel
On Fri, Aug 2, 2013 at 3:43 AM, Josef Kokeš j.ko...@apatykaservis.czwrote:
Hi!
For a long
On 2.8.2013 13:59, Alexis Diel wrote:
but LEFT JOIN is diferente of JOIN...
- LEFT JOIN brings all the data filtered from the FROM table, and
- JOIN brings only the data that have the ON condition in the JOINED table.
Which should make JOIN faster than LEFT JOIN, if anything, because it
But LEFT OUTER JOIN may cause the optimizer to scan through the table for
which all rows are being included in physical order while the INNER JOIN
might cause a plan where rows are read based on a scan through an index. If
rows aren't being filtered out, I can see how this might speed up the query
On Aug 2, 2013, at 11:25 AM, Louis Kleiman (SSTMS, Inc.) lklei...@sstms.com
wrote:
But LEFT OUTER JOIN may cause the optimizer to scan through the table for
which all rows are being included in physical order while the INNER JOIN
might cause a plan where rows are read based on a scan through
I can be wrong, but should make (JOIN) faster than (LEFT JOIN) only if the
joined condition is using index of the joined table.
I think that if u don't have a index for the joined condition it need to seek
in the whole table to filter.
In theory should not be difference between (JOIN) and
-- Original Message ---
From: Wewe sullen...@yahoo.com
select * from y
select value1+value2 as total from y
Which is better performance and speed? table x or table y ?
--- End of Original Message ---
I've never noticed a difference in performance at select time. I
--- In firebird-support@yahoogroups.com, Martijn Tonies wrote:
Hi Vlad,
Can someone let me know if the following is thread-safe:
- a client library from Firebird version 1, 1.5, 2 or 2.1
- using a connection per thread
- executing calls via multiple threads
Add also: protect
14 matches
Mail list logo
