Re: Fixing findDependentObjects()'s dependency on scan order(regressions in DROP diagnostic messages)

On Thu, Nov 15, 2018 at 10:52 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I think that the solution that you are proposing sorta sucks, but it's
> better than hacking objsubid to do it, which did in fact pass the
> laugh test, in that I laughed when I read it.  :-)

Probably a good idea to get another cup of coffee if I'm
pre-apologizing for my ideas.

> In a perfect world, it seems to me that what we ought to do is have
> some real logic in the server that figures out which of the various
> things we could report would be most likely to be useful to the user
> ... but that's probably a non-trivial project involving a fair amount
> of human judgement.  Reasonable people may differ about what is best,
> never mind unreasonable people.  I am inclined to think that your
> proposal here is good enough for now, and somebody who dislikes it
> (surely such a person will exist) can decide to look for ways to make
> it better.

Great. Actually, the on-disk size of the pg_depend heap relation is
*unchanged* in the attached WIP patch, since it fits in a hole
previously lost to alignment. And, as I said, the indexes end up
smaller with suffix truncation. Even if the only thing you care about
is the on-disk size of system catalogs, you'll still pretty reliably
come out ahead. The design here is squirrelly, but we're already
relying on scan order to reach objsubid = 0 entries first.

There is a single tiny behavioral change to the regression test output
with this patch applied. I think that that's just because there is one
place where this dependency management stuff interacts with pages full
of duplicates, and therefore stops putting duplicates in pg_depend
indexes in exactly DESC TID order. My other patches add a couple of
more tiny changes along similar lines, since of course I'm only doing
this with the pg_depend indexes, and not for every system catalog
index.

-- 
Peter Geoghegan