Thanks for all your replies:
The major problem is, that with firebird 2.1.3 the query also completes
within 3 seconds.
Something seems to have changed with the optimizer, execution plan or
whatever (~ sorry I dont know the terms here)
related to sorting, or double sorting, or sorting within
Hi
„select first(8) ID from TBL_TEST
where ID not in (select first(2) ID from TBL_TEST order by ID desc)
order by ID desc”
few things:
Just hint but „first” is not function First(8) is same as First 8
You should avoid NOT IN queries and use EXISTS/NOT EXISTS instead.
But
24.01.2020 15:19, Mark Rotteveel m...@lawinegevaar.nl [firebird-support] wrote:
> It sounds to me like this is should be optimized by executing the
> uncorrelated sub-queries only once.
Yes, but Firebird optimizer cannot do it.
--
WBR, SD.
On 2020-01-24 14:39, Dimitry Sibiryakov s...@ibphoenix.com
[firebird-support] wrote:
> 24.01.2020 14:29, Matthias Winkler spmm...@gmail.com [firebird-support]
> wrote:
>> I see the very same issue with firebird 3.0.4. Any ideas?
>
>You made nested loop on 18000*18000 records with sorting on
24.01.2020 15:01, Matthias Winkler spmm...@gmail.com [firebird-support] wrote:
> Is there a way to force limiting the result set before sorting it?
No. It is also meaningless because you in fact will get several
pseudo-random records.
Such result hardly have a practical purpose.
--
@SD: Is there a way to force limiting the result set before sorting it?
On Fri, Jan 24, 2020 at 2:55 PM Dimitry Sibiryakov s...@ibphoenix.com
[firebird-support] wrote:
> 24.01.2020 14:49, Matthias Winkler spmm...@gmail.com [firebird-support]
> wrote:
> > The result are just 8 entries. Sorting
24.01.2020 14:49, Matthias Winkler spmm...@gmail.com [firebird-support] wrote:
> The result are just 8 entries. Sorting those 3 entries should then take no
> time at all, right?
Wrong. Sorting happens before result set limit apply.
> Any ideas?
Rule number one: never use "not in".
The first to lines of the query alone give a result in ~3 seconds:
select first(8) ID from TBL_TEST
where ID not in (select first(2) ID from TBL_TEST order by ID desc)
The result are just 8 entries. Sorting those 3 entries should then take no
time at all, right?
But by adding the
24.01.2020 14:29, Matthias Winkler spmm...@gmail.com [firebird-support] wrote:
> I see the very same issue with firebird 3.0.4. Any ideas?
You made nested loop on 18000*18000 records with sorting on each itaretion.
It cannot
be fast.
--
WBR, SD.
2020. 01. 24. 14:29 keltezéssel, Matthias Winkler spmm...@gmail.com
[firebird-support] írta:
> @Mark: I see the very same issue with firebird 3.0.4. Any ideas?
I suggest try with 3.0.5 also.
Gabor
@Mark: I see the very same issue with firebird 3.0.4. Any ideas?
On Fri, Jan 24, 2020 at 1:46 PM Mark Rotteveel m...@lawinegevaar.nl
[firebird-support] wrote:
>
>
> On 2020-01-24 13:29, Matthias Winkler spmm...@gmail.com
> [firebird-support] wrote:
> > Hello,
> >
> > With Firebird 2.1.7 this
On 2020-01-24 13:29, Matthias Winkler spmm...@gmail.com
[firebird-support] wrote:
> Hello,
>
> With Firebird 2.1.7 this statement freezes my firebird server
> completely. Firebird will
> take 100% CPU.
>
>> select first(8) ID from TBL_TEST
>> where ID not in (select first(2) ID from TBL_TEST
Hello,
With Firebird 2.1.7 this statement freezes my firebird server completely.
Firebird will
take 100% CPU.
select first(8) ID from TBL_TEST
where ID not in (select first(2) ID from TBL_TEST order by ID desc)
order by ID desc
The used table has about 18`000 entries.
If I remove ONE of
HiThe most probability is that you store it twice in same transacion or other
connection do the same. Less probabiliti is that index is corrupted some way.
Regards,Karol Bieniaszewski
null
Have you tried doing the install interactively using ISQL?
How are you generating the "19", i.e. is there a chance that during debug
you have inserted and then rolled back or inserted then deleted a row with
that value. If it is using a generator, then it won't be re-used, i.e. if
you ran it
24.01.2020 09:48, Kjell Rilbe kjell.ri...@marknadsinformation.se
[firebird-support] wrote:
>
> If yes, will the changed write mode take effect immediately, or does it
> require a restart of the superserver process, all connections to be
> closed, or what? I.o.w. when does the changed write mode
24.01.2020 09:08, Kjell Rilbe kjell.ri...@marknadsinformation.se
[firebird-support] wrote:
> I assume this is caused by forced writes off and the fact that Windows
> may delay some writes for an arbitrary amount of time. In other words, I
> assume that the Firebird engine does in fact not write
Related to my preceding question:
Can I execute "gfix -write sync" and "gfix -write async" while the
database is in active use? I.e. while it has connections from a
supersevrer process?
If yes, will the changed write mode take effect immediately, or does it
require a restart of the
Den 2020-01-24 kl. 09:08, skrev Kjell Rilbe
kjell.ri...@marknadsinformation.se [firebird-support]:
>
> Hi,
>
> As posted here:
> https://dba.stackexchange.com/questions/258124/firebird-begin-backup-and-forced-writes-off-timestamp-update-delayed
>
>
> Feel free to reply here, at
Hi,
As posted here:
https://dba.stackexchange.com/questions/258124/firebird-begin-backup-and-forced-writes-off-timestamp-update-delayed
Feel free to reply here, at StackExchange, or both. I will make sure the
StackExchange question gets updated to show any helpful info that
appears here.
20 matches
Mail list logo
