> On 11/14/11 02:17, Vlad Khorsun wrote:
>> I thought about to change cache_writer in this direction - make it to do
>> "mini-flush"
>> instead of writting one page at time. But, note, we have no cache_writer
>> thread in CS\SC
>> and we can do a little (almost nothing) when page lock is dow
14.11.2011 2:17, Vlad Khorsun wrote:
> I thought about to change cache_writer in this direction - make it to do
> "mini-flush"
> instead of writting one page at time. But, note, we have no cache_writer
> thread in CS\SC
> and we can do a little (almost nothing) when page lock is downgraded (ofte
On 11/14/11 02:59, Adriano dos Santos Fernandes wrote:
> On 13-11-2011 19:48, Alexandre Benson Smith wrote:
>> I understand that such improvement could be hard to implement because of
>> the changes on the API and that the access libraries must be recoded for
>> such change, this could be a reas
On 11/14/11 02:17, Vlad Khorsun wrote:
> I thought about to change cache_writer in this direction - make it to do
> "mini-flush"
> instead of writting one page at time. But, note, we have no cache_writer
> thread in CS\SC
> and we can do a little (almost nothing) when page lock is downgrade
On 13-11-2011 19:48, Alexandre Benson Smith wrote:
>
> I understand that such improvement could be hard to implement because of
> the changes on the API and that the access libraries must be recoded for
> such change, this could be a reason to post pone this modification, but
> the argument tha
Em 13/11/2011 09:13, Dimitry Sibiryakov escreveu:
> 13.11.2011 12:09, Kjell Rilbe wrote:
>>> Іncrease table name and field name size above 32 symbols for support ORM
>>> frameworks sach as Ruby on Rails
>> Would be much appreciated, yes. ECO handle's the limitation
>> automatically, but a problem
>>> I really don't know well how Firebird does the page precedence graph,
>>> but if we could write all "independent" (say, the ones with the order
>>> they're write didn't matter) then call fdatasync and continues, would be
>>> much better than O_DSYNC mode.
>>>
>>> Is it possible? How generally i
On 13-11-2011 08:31, Vlad Khorsun wrote:
>> Let's remember the problem I initially observed. By default ext4 uses
>> barriers and that makes it much slower than ext3 (when ext3 wasn't using
>> barriers by default).
>>
>> But it slower only whens FW=ON. With FW=OFF there is almost no difference.
>>
Den 2011-11-13 12:13 skrev Dimitry Sibiryakov såhär:
> 13.11.2011 12:09, Kjell Rilbe wrote:
>>> Іncrease table name and field name size above 32 symbols for support ORM
>>> frameworks sach as Ruby on Rails
>> Would be much appreciated, yes. ECO handle's the limitation
>> automatically, but a probl
13.11.2011 12:09, Kjell Rilbe wrote:
>> Іncrease table name and field name size above 32 symbols for support ORM
>> frameworks sach as Ruby on Rails
>> >
> Would be much appreciated, yes. ECO handle's the limitation
> automatically, but a problem is that the 32 symbol limit is actually a
> 32 BYTE
Den 2011-11-11 16:54 skrev Anton Zibrov (JIRA) såhär:
> Іncrease table name and field name size above 32 symbols
>
>
> Key: CORE-3659
> URL: http://tracker.firebirdsql.org/browse/CORE-3659
> P
> Let's remember the problem I initially observed. By default ext4 uses
> barriers and that makes it much slower than ext3 (when ext3 wasn't using
> barriers by default).
>
> But it slower only whens FW=ON. With FW=OFF there is almost no difference.
>
> Barriers are supposed to act on file's meta
12 matches
Mail list logo
