Subject | Re: [Firebird-general] Re: [] Firdbird 2.0 vs the World |
---|---|
Author | = m. Th = |
Post date | 2006-12-30T17:38:13Z |
Dmitry Yemanov wrote:
from 1048576 to 67108864 in several steps for tables up to 30k records
on my workstation, did a SELECT * FROM <table> ORDER BY <field> + <Fetch
All> (sorted field is Varchar(100), and the table is pretty wide) and
the timings are the same (somewhere around 2,5 secs). IMHO, isn't worth
it. Sorry for this one.
hth and Happy new year!
m. th.
> = m. Th = wrote:Just let you know that I did some tests by changing SortMemBlockSize
>
>> b. SortMemBlockSize = 1048576 (ie. 1 MB) According with the amount
>> of RAM and with the Db sizes today perhaps is better to bump it at
>> (least) 4 MB. My value: 16777216 (16MB)
>>
>
> It saves you 15 memory allocations per big sort, but also wastes 16MB of
> memory per every small sort. I don't think this value requires a bump,
> although in some cases it could allow a bit better performance.
> Honestly, I often think about making it hardcoded (not configurable).
>
>
> Dmitry
from 1048576 to 67108864 in several steps for tables up to 30k records
on my workstation, did a SELECT * FROM <table> ORDER BY <field> + <Fetch
All> (sorted field is Varchar(100), and the table is pretty wide) and
the timings are the same (somewhere around 2,5 secs). IMHO, isn't worth
it. Sorry for this one.
hth and Happy new year!
m. th.