Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Are you planning to ignore my objections to it?
>
> > The author replied addressing your objections and I saw no reply from on
> > on that.
>
> He replied stating his opinion; my opinion didn't change. I was waiting
> for some other people to weigh in with their opinions. As far as I've
> seen, no one else has commented at all.
>
> If I get voted down on the point after suitable discussion, so be it.
> But I will strongly object to you applying the patch just because it's
> next in your inbox.
Tom, I have reviewed your objections:
> As I commented before, I am not in favor of this. I don't think that a
> four-byte savings justifies a forced initdb with no chance of
> pg_upgrade, plus loss of redundancy (= reduced chance of detecting or
> recovering from corruption), plus significantly slower access to
> several critical header fields. The tqual.c routines are already
> hotspots in many scenarios. I believe this will make them noticeably
> slower.
I don't think enough people use pg_upgrade to make it a reason to keep
an extra four bytes of tuple overhead. I realize 8-byte aligned systems
don't benefit, but most of our platforms are 4-byte aligned. I don't
consider redundency a valid reason either. We just don't have many
table corruption complaints, and the odds that having an extra 4 bytes
is going to make detection or correction better is unlikely.
The author addressed the slowness complaint and seemed to refute the
idea it would be slower.
Is there something I am missing?
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
