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

Поиск
Список
Период
Сортировка
От Henning Mälzer
Тема Question: Can i cut NON-HOT chain Pointers if there are no concurrent updates?
Дата
Msg-id 20121123141759.121640@gmx.net
обсуждение исходный текст
Список pgsql-cluster-hackers
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
describejust 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
tupleon 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
theywould 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
transactionsto 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



В списке pgsql-cluster-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: "pg_ctl promote" exit status
Следующее
От: ning chan
Дата:
Сообщение: pgsql replication feature