Subject | Re: [firebird-support] Why drop table can be sometime very very long ? |
---|---|
Author | Vander Clock Stephane |
Post date | 2011-09-02T17:23:20Z |
thanks ann !
On 8/30/2011 11:52 PM, Ann Harrison wrote:
>
> Stephane,
>
> >
> > > > 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)
> >
>
> Dropping a big table with lots of indexes will take longer than
> dropping an
> 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]
>
>
[Non-text portions of this message have been removed]