An idea for IPU ( We need another acronymn! ) - Mailing list pgsql-general

IPU, in place updates.
--------------------------

1/ Put a version numbers on each record represented by a byte/word sized
number from a three version number list kept by the table header. This
would then only involve one more byte per record. This version number
list needs to be the VERY first item in the table header. The lowest
ordered byte of the first word of the version number list contains the
size of the words in bytes. The version number list's version number is
the second word in the structure. ( we shouldn't run out of 2^16, 2^32,
2^64, 2^128, or 2^256 versions list versions ).

2/
    A/ Put a field in the table version number list showing status of
that version number:
       No rows of this number.
       Some rows of this number
       All rows of this number.

    B/ An additional field tags whiuch version number the table header
is at.

    C/ The lowest version number is removed when it says it has no rows.
and the table header is at a higher number.

3/  Repeat the same for the indexes.

4/  The tables/indexes features can only be accessed by the version
marked as the table header.

5/ The read/write modules/objects for the backend is a DLL that is
changed dynamically some sort of flagging system. Any NEW backend
process gets the NEW DLL; Cuirrently executing ones keep the one they
started with.

6/ An additinonal two processes are always part of the backend:
    A/ A scheduler for updates, which has programmable bandwidth
adjustment paramaters for what percentages of various resources are
given to do updates in place.
    B/ The upate process itself. If all tables, indexes, and other
structures are updated, well, it's inactive.

7/  The same structure for the table and row versioning is used for the
database and table versioning, and the schema and database versioning.

8/ Once a new DLL is loaded that contains the necessary information to
read and write the old records, the uudate process starts automagically.

9/ For the listing/treeing structures changes on the
table/database/schema level, the same multiple version numbers are used
and another autonimous process slowly morphs that also. This is probably
more challenging, and might require a copy of both kinds of structures
in existence and the data slowly moving from one to the other. Until the
new structure is COMPLETELY built, the old structure contains pointers
to the locationi in the new structure if the item is there. When both
structures point completely to the new structure's contents, the old
structure's reading code is demoted and the new structure's takes over.

10/ Databases and Schemas do the same thing as 9.


anyway, some thoughts.