Hi all,
i'm trying to combine the new Window functions in Fb3 with
recursive CTEs to get a _defined_ ordering of the recursive
child records in the result set.
Since we don't have "DEPTH FIRST BY " or
"BREADTH FIRST BY " clauses in recursive CTEs
yet, i'm trying to work around this by using the n
Hi,
I'm a bit puzzled by the results I get
I made test on Fedora 16 with Kernel 3.1.1-1.fc16.x86_64 on LVM2 Logical
Volume of 10G
Firebird 2.5.1 Classic
hdparm /dev/vg_tests/testfb
/dev/vg_tests/testfb:
multcount = 0 (off)
IO_support= 1 (32-bit)
readonly = 0 (off)
readahead
17.11.2011 4:39, Frank Ingermann wrote:
>
> a) [ ] file it as a bug - this _should_ work!
This would get my vote, as it works fine (and returns rows in the
expected order) in PGSQL.
Dmitry
--
All the data continuously
17.11.2011 12:59, Philippe Makowski wrote:
>
> I really wonder if we can't get MaxUnflushedWrites or something like
> that under Linux too
> I would be curious to do same test with this parameter under Linux
It works for all platforms, you just need to uncomment and set it up in
firebird.conf.
Dmitry Yemanov [2011-10-25 17:55] :
> 25.10.2011 14:39, Philippe Makowski wrote:
>
>> in fact with theses settings, FW=OFF is safer than before
>> safe enough to be the default ?
>
> Even in the "paranoid mode" (MaxUnflushedWrites = 1) they still don't
> guarantee the write order. So, if the cr
On 11/17/11 11:37, Dmitry Yemanov wrote:
> 17.11.2011 11:26, Alex Peshkoff wrote:
>
>> And one more interesting line:
>> open("./fb_init", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 7
>> Why is _SHARED_ file opened in CWD? It should go to /tmp/firebird.
> Because he explicitly sets FIREBIRD_LOCK to CWD b
Hello,
the previously reported bug in the Trace API is a bit nasty for
customers how are extensively using the Trace stuff.
I wonder if there is some kind of time frame for releasing 2.5.2
available, because for people coming from 2.1, they can't download 2.5.0
from the official Firebird websi
17.11.2011 13:49, Thomas Steinmaurer wrote:
>
> the previously reported bug in the Trace API is a bit nasty for
> customers how are extensively using the Trace stuff.
>
> I wonder if there is some kind of time frame for releasing 2.5.2
> available, because for people coming from 2.1, they can't dow
17.11.2011 13:25, Philippe Makowski wrote:
> hum
> would it be hard to have it in the good order
Impossible, IMHO. The entire idea of the combined writes (FW=OFF +
MaxUnflushed* set up) is that pages are written into the file system
cache (and it doesn't not guarantee any disk writes) and then
Dmitry,
> 17.11.2011 13:49, Thomas Steinmaurer wrote:
>>
>> the previously reported bug in the Trace API is a bit nasty for
>> customers how are extensively using the Trace stuff.
>>
>> I wonder if there is some kind of time frame for releasing 2.5.2
>> available, because for people coming from 2.
On 17/11/2011 07:52, Dmitry Yemanov wrote:
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
Or to flush group of independent pages at once, like I proposed. I think
this can be a great improvement for FW=ON.
Adriano
--
Dmitry Yemanov [2011-11-17 10:52] :
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
and that's what cost a lot
so without WAL, no clear guarantied solution
but WAL is another problem
I see
---
Adriano dos Santos Fernandes [2011-11-17 11:14] :
> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>> The only way to guarantee ordered writes is to flush individual pages
>> and this is what FW=ON does.
>
> Or to flush group of independent pages at once, like I proposed. I think
> this can be a gr
17.11.2011 14:14, Adriano dos Santos Fernandes wrote:
> Or to flush group of independent pages at once, like I proposed.
Sure. I was speaking about the current code only.
Dmitry
--
All the data continuously generated i
> Dmitry Yemanov [2011-10-25 17:55] :
>> 25.10.2011 14:39, Philippe Makowski wrote:
>>
>>> in fact with theses settings, FW=OFF is safer than before
>>> safe enough to be the default ?
>>
>> Even in the "paranoid mode" (MaxUnflushedWrites = 1) they still don't
>> guarantee the write order. So,
Dmitry Yemanov [2011-11-17 10:10] :
> 17.11.2011 12:59, Philippe Makowski wrote:
>>
>> I really wonder if we can't get MaxUnflushedWrites or something like
>> that under Linux too
>> I would be curious to do same test with this parameter under Linux
>
> It works for all platforms, you just need t
On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>> The only way to guarantee ordered writes is to flush individual pages
>> and this is what FW=ON does.
> Or to flush group of independent pages at once, like I proposed. I think
> this can be a
On 17/11/2011 09:19, Alex Peshkoff wrote:
> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>>> The only way to guarantee ordered writes is to flush individual pages
>>> and this is what FW=ON does.
>> Or to flush group of independent pages at
> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
>>> The only way to guarantee ordered writes is to flush individual pages
>>> and this is what FW=ON does.
>> Or to flush group of independent pages at once, like I proposed. I think
>> this can
On 11/17/11 15:37, Vlad Khorsun wrote:
>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is what FW=ON does.
>>> Or to flush group of independent pages a
On 11/17/11 15:23, Adriano dos Santos Fernandes wrote:
> On 17/11/2011 09:19, Alex Peshkoff wrote:
>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
>>> On 17/11/2011 07:52, Dmitry Yemanov wrote:
The only way to guarantee ordered writes is to flush individual pages
and this is
17.11.2011 15:37, Vlad Khorsun wrote:
> And, note, most heavy case (flush on commit) is already optimized.
With FW=ON, it's optimized only for better write order (less HDD head
movements). But AFAIU we're talking here about batched writes instead of
singleton writes.
Dmitry
-
> On 11/17/11 15:37, Vlad Khorsun wrote:
>>> On 11/17/11 14:14, Adriano dos Santos Fernandes wrote:
On 17/11/2011 07:52, Dmitry Yemanov wrote:
> The only way to guarantee ordered writes is to flush individual pages
> and this is what FW=ON does.
Or to flush group of independent p
Now it gives an error
http://dir.gmane.org/gmane.comp.db.firebird.devel
I have requested to be fixed in this thread
http://thread.gmane.org/gmane.discuss/14421
Here is the related thread and news
http://www.firebirdnews.org/?p=6460
--
On 16-11-2011 22:39, Frank Ingermann wrote:
>
> ...but it leads to an endless loop/recursion (using latest Fb3 beta)
> :-(
>
Before decide what to do, I'd like to hear Vlad about the error
isc_dsql_cte_wrong_clause, which, for example, happens if a recursive
query has a GROUP BY.
Why is it not
> On 16-11-2011 22:39, Frank Ingermann wrote:
>>
>> ...but it leads to an endless loop/recursion (using latest Fb3 beta)
>> :-(
>>
>
> Before decide what to do, I'd like to hear Vlad about the error
> isc_dsql_cte_wrong_clause, which, for example, happens if a recursive
> query has a GROUP BY.
>
26 matches
Mail list logo
