Tom Lane <tgl@sss.pgh.pa.us> writes:
> "Jim C. Nasby" <jim@nasby.net> writes:
> > ... place a limit on the number of transactions that can be live in a table
> > at once.
>
> Urk, well maybe, but ...
>
> > you could shrink all the visibility info to 1 byte if you
> > wanted to.
>
> ... 256 of 'em is surely not an acceptable limit.
The plan Gavin Sherry and I were discussing at the Code Sprint was to store a
single "most common xmin" xmin in the per-page special area. Then have a bit
on each tuple indicating that the xmin isn't present in the tuple and instead
to use the xmin from the page footer. Any tuples with other values of xmin
would have to store that xmin normally.
The use case here is primarily tables loaded in large batch jobs that have
large swaths of the table, possibly the entire table, loaded in the same
transaction.
My thinking was that "most common xmin" could be very approximate. In fact my
my plan was to just store the first xmin the page sees there. This catches the
common use cases of pg_restore or COPY loading many records and even catches
most cases of large inserts into existing tables whenever they extend the
table.
A further refinement could be to have vacuum look for the actual most common
xmin and rewrite the page using it. If there's enough free space it may be
worthwhile storing InvalidTransactionId and allowing the next insert to set
the "most common xmin".
However I'm not convinced of the importance of this refinement. The thing to
remember is that shaving bits off tuples is not a goal in itself. It's a means
to an end, namely packing more tuples on a page. If we shave off 4 bytes off
every tuple when we're loading thousands of tuples then we get to put more of
them on a page. If we save space on tuples when we're running vacuum that just
gives us more free space in the free space map and we only see a benefit down
the line if we end up eventually filling up that space.
--
greg