Re: [Firebird-devel] Database page sizes WAS: Major changes in ODS 12

[Vlad K. <hv...@us...>]

> Vlad,
>
>> >> >> Do you believe in faster performance using bigger pages?
>> >> >
>> >> > Yes!
>> >> >
>> >> > Disk sub-systems are supporting larger and larger block sizes.
>> >> >
>> >> > It would seem logical for the database to support larger page sizes,
>> to
>> >> take advantage of the disk functionality.
>> >>
>> >>     Think about writes also.
>> >>
>> >>     The "slow read" issue can be solved with special allocation policy
>> and
>> >> multy-page reads. I.e. allocate few consecutive pages at time (say 8)
>> and
>> >> read them all at once, if big scan is performed.
>> >
>> > If the disk blocks are 256KB then 256KB bytes will be read/written to
>> disk, regardless if the database page is smaller.
>>
>>     Disk blocks ? Are you refer to file system cluster size ? Or to the
>> RAID stripe size ?
>
> System cluster size or Stripe size, they are different words for essentially the same thing.

    The main point is that they are not disk block size.

>> > So, allowing the database page size to be 64KB (or even larger) if the
>> disk block size is 256KB has no disk IO cost!
>>
>>     You are wrong, sorry. Write of 4KB can't be the same as write of
>> 256KB, even if this 256KB is "one block".
>
> Yes it is.  If the stripe/block size is 256KB, then 256KB is what the OS will transfer to the disk controller to be written to 
> disk.

    It is easy - don't set such huge block at file system\RAID level if you going
to work with database. It is good for streaming video but not for database.
Ask any DBA what stripe size they choose for RAID.

>> Think also about disk controller cache which made writes
>> fast - it is not unlimited
>> size. Don't you think this is really stupid to write 256KB because of
>> change of 200 bytes ?
>
> Stupid or not, that is what is actually happening!

    It happens only with bad configured system.

>> > Don't get me wrong, correct page sizing will be a balancing act.
>>
>>     Sure, but in reasonable borders.
>
>
>> > But that is something which will vary based on hardware and application
>> requirements.
>> >
>> > The engine/we should impose a limit because we think there might be a
>> problem, when we know that there are
>> > cases where larger pages will be beneficial.
>>
>>     We know ? You know ? I'm - not. Show me the real DBMS which support
>> such page size and test showing this fat pages is good (not read-only
>> test, please)...
>
> You misunderstand, the variability of the page size problem is beyond any synthetic test that you or I can/should produce.

    Provide real-life test if you don't like synthetic :) Ok, you have no test, i understand.
Then provide any kind of proof of your theory, not just a plain words.

> It is for the developer/admin to determine the right page size for themselves.

    See above - admin must understand database requirements.

> We simply need to "get out of the way" and provide support for larger page sizes, to allow them to do what they need to do.

    Arguments ? So far i see no need for such feature.

Regards,
Vlad