Re: Getting rid of cmin and cmax

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
>> Saving 4 bytes per tuple with the phantom cid is nice, but saving 8
>> bytes (assuming we get rid of xvac in the future, or overlay it with
>> xmin for example) is even better.
>
> xvac is not going away, so that argument is unconvincing,

The use case for vacuum full has been narrowing steadily over time. I'm not
sure there's much left of it these days. In every case where it comes up on
list people are inevitably just confused and don't need it. In the few cases
where it's actually suggested we invariably recommend one of the various
commands that rewrite the entire table instead.

The main fundamental problem with rewriting the entire table is that you may
not have enough storage to do so and I think there may be better ways of
avoiding that than always storing 4 bytes in every tuple of every table just
in case we want to run vacuum full one day.

> and I don't believe you can avoid blowing out local memory if you have to
> remember each tuple's cmin/cmax separately. (Notice that Manfred gave up on
> his patch for lack of a spill-to-disk mechanism.)

spill to disk would certainly be a requirement. In the cases where it's needed
the data has to be stored somewhere, it just doesn't have to go through WAL
and take up table space when no other backend will every be interested in it.

> I'm also concerned about loss of debug traceability if these fields
> disappear entirely from disk --- it's been handy more than once to be
> able to tell where in a complex transaction something happened.

That's an interesting thought. I'm not sure what scenario you're picturing
though. You would still have xmin/xmax so it when do you need to look at cmin
to know when something happened?

You could certainly imagine a guc setting that would force the spill to disk
to always even when the data isn't needed. It seems like a poor substitute for
some dedicated tracing mechanism targeted specifically at the info needed for
debugging.

> Lastly, at least on machines with 8-byte MAXALIGN, removing four more
> bytes from heap headers would save nothing.

Well there still exist plenty of 4-byte MAXALIGN machines out there. But the
more serious problem with this argument is that it comes up repeatedly. If we
pass up 4 bytes here and 4 bytes there pretty soon we're talking about real
data. Well, at least 8 bytes.

Getting rid of cmin, cmax, xvac and in some cases xmin (as discussed at the
code sprint) leaves us in much better shape even though any one of those
doesn't necessarily buy us much.

> So I'm not excited about going through enormous pushups to get rid of both
> fields, when a far simpler and better-performing mechanism suffices to
> remove one.

Frankly the whole phantom commandid thing sounds more complicated. You *still*
need a local state data structure that *still* has to spill to disk and now
it's much harder to characterize how large it will grow since it depends on
arbitrary combinations of cmin and cmax.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com