Re: On-disk Tuple Size

On Sat, 20 Apr 2002, Tom Lane wrote:

> Curt Sampson <cjs@cynic.net> writes:
> > While we're at it, would someone have the time to explain to me
> > how the on-disk CommandIds are used?
>
> To determine visibility of tuples for commands within a transaction.
> Just as you don't want your transaction's effects to become visible
> until you commit, you don't want an individual command's effects to
> become visible until you do CommandCounterIncrement.  Among other
> things this solves the Halloween problem for us (how do you stop
> an UPDATE from trying to re-update the tuples it's already emitted,
> should it chance to hit them during its table scan).
>
> The command IDs aren't interesting anymore once the originating
> transaction is over, but I don't see a realistic way to recycle
> the space ...

Ah, I see. So basically, it's exactly parallel to the transaction IDs
except it's for commands instead of transactions?

So this seems to imply to me that the insert command ID fields are of
interest only to the transaction that did the insert. In other words, if
your transaction ID is not the one listed in t_xmin, the t_cmin field is
always ignored. And the same goes for t_cmax and t_xmax, right?

If this is the case, would it be possible to number the commands
per-transaction, rather than globally? Then the t_cmin for a particular
tuple might be say, 7, but though there might be many transactions that
have processed or will process command number 7, we would know which
transaction this belongs to by the t_xmin field.

Does this work for cursors, which currently seem to rely on a global
command ID? If you keep track of the transaction ID as well, I think so,
right?

Having per-transaction command IDs might allow us to reduce the range of
the t_cmin and t_cmax fields. Unfortunately, probably by not all that
much, since one doesn't want to limit the number of commands within a
single transaction to something as silly as 65536.

But perhaps we don't need to increment the command ID for every command.
If I do an insert, but I know that the previous command was also an
insert, I know that there were no intervening reads in this transaction,
so can I use the previous command's ID? Could it be that we need to
increment the command ID only when we switch from writing to reading
or vice versa? There could still be transactions that would run into
problems, of course, but these might all be rather pathological cases.

Or is everybody wishing they had some of whatever I'm smoking? :-)

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC