[firebird-support] Re: Is NOT IN or SMALLINT = 1 efficient?

2012-02-21 Thread venussoftop
--- In firebird-support@yahoogroups.com, Mark Rotteveel mark@... wrote: On Mon, 20 Feb 2012 09:51:19 -, venussoftop venussoftop@... wrote: Hi all I have tables that can allow me to filter data like this: SELECT a.* FROM tablea a WHERE a.iTableBLinkID NOT IN (SELECT

RE: [firebird-support] Force query plan to filter before join (Arno)

2012-02-21 Thread Svein Erling Tysvær
Hi Arno! Is Firebird intelligent enough to use an index for PROJECT.ASSIGNMENT_STATUS != 'UNASSIGNED' when over 99% of the data contains 'UNASSIGNED'? I thought we had to wait for Firebird 3 to see histograms and that 'not equal' would not be able to efficiently use an index before that?

Re: [firebird-support] Backup-Restore, without killing existing attachments.

2012-02-21 Thread Elmar Haneke
I have a question on backup/restore. Think of a firebird classic on a linux box. -Do a backup with existing attachments -After backup, Rename the old gdb file to something else -Restore the backup file with the original gdb name. You have to kill all connected clients before starting

[firebird-support] Re: Backup-Restore, without killing existing attachments.

2012-02-21 Thread arda
Hi, I get your point. But I wonder what can happen when we don't kill the existing clients before restoring with the same database file name. Actually I had a bad exprience on this :) -One client remained active after a restore operation and continued to run on the newly restored database.

RE: [firebird-support] Re: Backup-Restore, without killing existing attachments.

2012-02-21 Thread bogdan
Actually, active users stay connected to old renamed database. It can happen only on linux, never on Windows. Regards Bogdan Hi, I get your point. But I wonder what can happen when we don't kill the existing clients before restoring with the same database file name. Actually I had a bad

Re: [firebird-support] Force query plan to filter before join

2012-02-21 Thread Alec Swan
Set and Arno, Thank you both of you for your solutions! Arno's solution required swapping the order of PROJECT and PROJECT_CODE_DESCRIPTOR tables in the join and use LEFT JOIN instead of INNER JOIN to join them. This is so simple and the results are amazing. PLAN SORT (JOIN (JOIN (JOIN (PROJECT