Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What I'm considering is this: scan pg_shdepend looking for objects to
> delete, and save them into a list; but each time we find one, we also
> find objects that depend on it.  Those dependent objects should be
> ignored; but we should also remove from the list of objects to delete,
> any dependent object that we added in a previous iteration of the
> pg_shdepend scan.

Um ... but this doesn't seem to acknowledge the idea that we should
distinguish whether those dependent objects are owned by the user or

What I was thinking of was

        find all target objects using pg_shdepend, make an
                ObjectAddresses list of them

        for (each item of list)
                if (already deleted)
                if (implicit dependency of some later list item)
                pass item to performDeletion, with entire list
                        as oktodelete context

This will require some cooperation from dependency.c: the standard
performDeletion entry point doesn't let you pass in an oktodelete list,
and it would be nice if "performDeletionWithList" or whatever we
call it provided some feedback about what it'd deleted so that the
bookkeeping effort implicit in "if (already deleted)" could be

> This has a nasty looking O(n^2) behavior, but I don't see anything
> better.

In my formulation the O(N^2) behaviors are limited to searching the
oktodelete list, which at least is a pretty tight inner loop.  The
dependency.c code was not designed with the idea that oktodelete would
ever get really large ... perhaps later we could revisit that data
structure, but for now I think this'll be good enough.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to