Subject | Re: [firebird-support] Why drop table can be sometime very very long ? |
---|---|
Author | Ann Harrison |
Post date | 2011-08-30T19:52:39Z |
Stephane,
empty table because of the amount of work done. Each page used by the table
must be marked free on its Page Inventory Page.
To release a data page, Firebird reads the RDB$PAGES table to find pointer
pages and marks the pages listed on the pointer pages as free until the page
is empty, then removes the pointer page entry from RDB$PAGES, then marks the
pointer page as free on its page inventory page. If enough entries are
removed from RDB$PAGES to free up pages there, then those pages are also
released, using the same algorithm.
To release index pages, Firebird must read the whole index. It's been a
very long time since I looked at the code that removes an index, but my
recollection is that it goes to the lowest level of the index and releases
pages from left to right, following the sibling pointers, then starts from
the top again and releases the next level up.
Checking the performance statistics for the number of pages read and written
will help you understand what's going on.
Good luck,
Ann
[Non-text portions of this message have been removed]
>Dropping a big table with lots of indexes will take longer than dropping an
> > > when i do drop table, sometime it's take hours to return (especially on
> > > big table)
> > > why ?
> >
>
> no, the database have only one client connected, the client that do the
> drop table ...
> it's not failed, it's just very very long !
> as soon as it success, creating again and deleting again the table is
> very fast !
> i thing it's connected with the number or reccord in the table (in my
> case lot of, and lot of index too)
>
empty table because of the amount of work done. Each page used by the table
must be marked free on its Page Inventory Page.
To release a data page, Firebird reads the RDB$PAGES table to find pointer
pages and marks the pages listed on the pointer pages as free until the page
is empty, then removes the pointer page entry from RDB$PAGES, then marks the
pointer page as free on its page inventory page. If enough entries are
removed from RDB$PAGES to free up pages there, then those pages are also
released, using the same algorithm.
To release index pages, Firebird must read the whole index. It's been a
very long time since I looked at the code that removes an index, but my
recollection is that it goes to the lowest level of the index and releases
pages from left to right, following the sibling pointers, then starts from
the top again and releases the next level up.
Checking the performance statistics for the number of pages read and written
will help you understand what's going on.
Good luck,
Ann
[Non-text portions of this message have been removed]