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

Let's get no-disk-format upgrades working first.

---------------------------------------------------------------------------

Dennis Gearon wrote:
> 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.
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073