On Tue, Apr 20, 2021 at 8:21 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:>
> Thomas Munro <thomas.munro@gmail.com> writes:
> > For example, if you think there actually is a potential better
> > plan than using pg_depend for this, that'd definitely be good to know
> > about.
>
> I really dislike using pg_depend, for a couple of reasons:
>
> * You've broken the invariant that dependencies on pinned objects
> are never recorded. Now, some of them exist, for reasons having
> nothing to do with the primary goals of pg_depend. If that's not
> a sign of bad relational design, I don't know what is. I didn't
> look at the code, but I wonder if you didn't have to lobotomize
> some error checks in dependency.c because of that. (Perhaps
> some sort of special-case representation for the default
> collation would help here?)
Hmm, OK, thanks, that's something to go back and think about.
> * pg_depend used to always be all-not-null. Now, most rows in it
> will need a nulls bitmap, adding 8 bytes per row (on maxalign=8
> hardware) to what had been fairly narrow rows. By my arithmetic
> that's 13.3% bloat in what is already one of our largest
> catalogs. That's quite unpleasant. (It would actually be
> cheaper to store an empty-string refobjversion for non-collation
> entries; a single-byte string would fit into the pad space
> after deptype, adding nothing to the row width.)
That seems like a good idea.
> > Hrmph. Yeah. We didn't consider types that change later like this,
> > and handling those correctly does seem to warrant some more thought
> > and work than we perhaps have time for. My first thought is that we'd
> > need to teach it to trigger reanalysis.
>
> That seems like a nonstarter, even before you think about race
> conditions.
Yeah, that runs directly into non-trivial locking problems. I felt
like some of the other complaints could conceivably be addressed in
time, including dumb stuff like Windows default locale string format
and hopefully some expression analysis problems, but not this. I'll
hold off reverting for a few more days to see if anyone has any other
thoughts on that, because there doesn't seem to be any advantage in
being too hasty about it.
