Interesting Ivan

And a cycle backup/restore doesn't force each row to keep in a single page?

If having a row in several pages causes bad performance it has sense trying
to keep that rows as grouped as possible. Or not?

Greetings.

Walter.

On Thu, May 2, 2013 at 11:11 AM, Ivan Přenosil <Ivan.Prenosil@...>wrote:

> **
>
>
>
> > as I now understand it, if I restore the database with -USE_ALL_SPACE &
>
> > then do gfix -use reserve I will have a database which has all the static
>
> > data on full pages and the data that does change will quickly go back to
>
> > the 80/20 page usage. Something like 90% is static so I'm hoping this
> will
>
> > give me some improved performance on queries against the static data.
>
> It depends - do you want to update only new data, or those restored with
>
> use_all_space too ? The problem is that UPDATE will never change
>
> record's location, it will stay on "it's" page "forever".
>
> So, in "normal" database, when you update the record, FB will store
>
> the record and its older version(s) on the same page (if free space on
> that
> page
>
> is sufficient). Thus, update will touch only single page, garbage
> collection
>
> will also touch single page (not counting indexes etc).
>
> In "your database" :) when you update the record on 100% filled page,
>
> FB will store the new data on original place/page, whereas backversion
>
> on another page. Thus, update and garbage collection will both
>
> touch at least two pages each.
>
> I.e. you get worse performance.
>
> And that is not all - when you update the record such that it requires more
>
> space to store, the record still has to remain on the original page,
>
> but since there is not enough room, it becomes fragmented - part is stored
>
> on original page, part on new page.
>
> Thus it will affect all subsequent oprations with such record -
>
> whenever you read that record, FB will have to read 2 db pages !
>
> Ivan
>
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]