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
not.
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)
continue;
if (implicit dependency of some later list item)
continue;
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
minimized.
> 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
