Question: Can i cut NON-HOT chain Pointers if there are no concurrent updates?

Hello,

Can somebody help me?

I am trying to answer a question to implement a new concept in postgresql.
What i do is some sort of reorganizing heapfiles where the whole concept would be to much for this mail. So i try to describe just the problem.

Question:
What would be the loss if i cut NON-HOT chain Pointers, meaning i set t_ctid=t_self in the case where it points to a tuple on another page?

The Tuples can be found over the index, because NON-HOT Tuple versions have their own index entry.
index_getnext does not follow these pointers.
They would also be found by heap_getnext.

Whithin updated tuples there is also xmax set, so later transactions would recognize it as deleted and not updated, but they would find the new version afterwards.

I make sure to have no concurrent transactions on the same heapfile by getting a snapshotAny and waiting for all other transactions to end.
After that all new transactions will write new tuples to a new heapfile.
Within the old heapfile there will be just deletes, which are in-place.
I Synchronise heapfile operations with BUFFER_LOCK_SHARE / BUFFER_LOCK_EXCLUSIVE.

My algorithm would have much better performance and would be simpler, because i could work on a page-per-page basis.
I run it just once on each table. Afterwards the tuples can be updated as usual.

So the Question is for the later effects.
What is the loss? Would vacuum have any problem?

I am working on a project based on "postgres (PostgreSQL) 8.5devel" with the code from several master thesises befor me.

Thanks for answers.
Henning

Henning,

On 11/23/2012 03:17 PM, "Henning Mälzer" wrote:
> Can somebody help me?

Sure, but you might get better answers on the -hackers mailing list. I'm
redirecting there. The cluster-hackers one is pretty low volume and low
subscribers, I think.

> Question:
> What would be the loss if i cut NON-HOT chain Pointers, meaning i set t_ctid=t_self in the case where it points to a tuple on another page?

READ COMMITTED would stop to work correctly in the face of concurrent
transactions, I guess. See the fine manual:

http://www.postgresql.org/docs/devel/static/transaction-iso.html#XACT-READ-COMMITTED

The problem essentially boils down to: READ COMMITTED transactions need
to learn about tuples *newer* than what their snapshot would see.

> I am working on a project based on "postgres (PostgreSQL) 8.5devel" with the code from several master thesises befor me.

Care to elaborate a bit? Can (part of) that code be released under an
open license?

Regards

Markus Wanner