Tom,
thanks for answering.
On Thu, 02 May 2002 17:16:38 -0400, you wrote:
>The hole in this logic is that there can be multiple active scans with
>different values of CurrentCommandId (eg, within a function
>CurrentCommandId may be different than it is outside). If you overwrite
>cmin with cmax then you are destroying the information needed by a scan
>with smaller CurrentCommandId than yours.
Oh, I see :-(
Let me throw in one of my infamous wild ideas in an attempt to rescue
my proposal: We have 4 32-bit-numbers: xmin, cmin, xmax, and cmax.
The only case, where we need cmin *and* cmax, is, when xmin == xmax.
So if we find a single bit to flag this case, we only need 3
32-bit-numbers to store this information on disk.
To keep the code readable we probably would need some accessor
functions or macros to access these fields.
As of 7.2 there are three unused bits in t_infomask.
>
>> (Q4) Is it really easy to change the size of HeapTupleHeaderData? Are
>> the data of this struct only accessed by field names or are there
>> dirty tricks using memcpy() and pointer arithmetic?
>
>AFAIK there are no dirty tricks there. I am hesitant to change the
>header layout without darn good reason, because it breaks any chance
>of having a working pg_upgrade process. But that's strictly a
>production-system concern, and need not discourage you from
>experimenting.
Is saving 4 bytes per tuple a "darn good reason"? Is a change
acceptable for 7.3? Do you think it's worth the effort?
> We haven't worked out exactly how nested transactions would
>work, but to the extent that they are handled as different CommandIds
>we'd have the same issue already mentioned: we should not assume that
>execution of different CommandIds can't overlap in time.
Assuming that a subtransaction is completely contained in the outer
transaction and there is no activity by the outer transaction while
the subtransaction is active, I believe, this problem can be solved
...
It's late now, I'll try to think clearer tomorrow.
Good nightManfred
