Re: Reduce heap tuple header size - Mailing list pgsql-patches

Bruce Momjian wrote:
>
> 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 non-overwriting storage management (which is one reason why whe need
all these header fields) causes over 30 bytes of row overhead anyway. I
am with Tom here, 4 bytes per row isn't worth making the tuple header
variable length size.

> The author addressed the slowness complaint and seemed to refute the
> idea it would be slower.

Do we have any hard numbers on that? Is it just access to the header
fields, or do we loose the offset cacheability of all fixed size fields
at the beginning of a row? In the latter case count me into the
slowness-believer camp.


Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #