Re: pg_depend

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bill Studenmund <wrstuden(at)zembu(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alex Pilosov <alex(at)pilosoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_depend
Date: 2001-07-17 23:13:10
Message-ID: 28758.995411590@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bill Studenmund <wrstuden(at)zembu(dot)com> writes:
> I think it's actually O(N^M) where there are N system objects and a chain
> of M dependencies (A depends on B which depends on C => M = 3).

It's probably not *that* bad. It's reasonable to assume that only a
small number of objects actually depend directly on any one object you
might want to delete. (Performance of deleting, say, the int4 datatype
is probably not of major interest ;-) ...) Only for those objects, not
for all N, would you need to descend to the next level of search.

Nonetheless, a properly indexed pg_depend table would allow you to find
these objects directly, and again to find their dependents directly,
etc. The brute force approach would require a rather expensive scan
over all the system catalogs, plus nontrivial analysis for some types
of system objects such as functions. Repeating that for each cascaded
delete is even less appetizing than doing it once.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bill Studenmund 2001-07-17 23:24:01 Re: pg_depend
Previous Message Bill Studenmund 2001-07-17 22:09:28 Re: pg_depend