Actually, if you need to squeeze a few more bits into that word, the
> thing to do would be to get rid of storing the tuple length there.
> This would involve adding the same type of indirection header that
> we use for HeapTuples, so that the length would be available at need
> without going back to the item pointer. I
I feel the other one is easy. To store the hint bits inside the ItemId, in
the place of size. We have 16 bits there.Whenever the size is required, we
need to follow the offset and goto the corresponding tuple and then take the
size from there. The change seems to be minimal, but please bear with me, if
i am very ignorant about something.
> Squeezing cmin in there is just fantasy though.
I think we can get away with this, by making the person, who inserts and
selects in the same transaction to go and find the visibility through heap.
In the Index tuple hint bits, we can note down, if the command is a simple
insert/update/delete. By Simple insert, i mean that it doesn't have a
select. So if that is the case, it can be made visible to statements within
the same transaction. We can even document, that people can just insert a
savepoint between their insert and select. This would increase the xid and
make that tuple visible within the same transaction. All that seems to be
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-02-26 04:15:29|
|Subject: Re: Allow vacuumdb to only analyze|
|Previous:||From: Robert Haas||Date: 2010-02-26 04:01:14|
|Subject: Re: Avoiding bad prepared-statement plans.|