Changeset: 81afe959ccbd for MonetDB URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=81afe959ccbd Modified Files: gdk/gdk.h gdk/gdk_atoms.c gdk/gdk_batop.mx Branch: headless Log Message:
Merge with new COLelement change diffs (truncated from 8896 to 300 lines): diff --git a/MonetDB.spec b/MonetDB.spec --- a/MonetDB.spec +++ b/MonetDB.spec @@ -27,7 +27,7 @@ Group: Applications/Databases License: MPL - http://monetdb.cwi.nl/Legal/MonetDBLicense-1.1.html URL: http://monetdb.cwi.nl/ -Source: http://dev.monetdb.org/downloads/sources/Mar2011/%{name}-%{version}.tar.gz +Source: http://dev.monetdb.org/downloads/sources/Mar2011/%{name}-%{version}.tar.bz2 BuildRequires: bison BuildRequires: bzip2-devel diff --git a/gdk/gdk.h b/gdk/gdk.h --- a/gdk/gdk.h +++ b/gdk/gdk.h @@ -292,7 +292,7 @@ * * These are much used operations on COLs, such as aggregate functions * and relational operators. They are implemented in terms of COL- and - * BUN-manipulation GDK primitives. + * oid-manipulation GDK primitives. * @end table * * @+ Interface Files @@ -487,7 +487,7 @@ #define IDLENGTH 64 /* maximum COL id length */ #define COLMARGIN 1.2 /* extra free margin for new heaps */ #define COLTINY_BITS 8 -#define COLTINY ((BUN)1<<COLTINY_BITS) /* minimum allocation buncnt for a COL */ +#define COLTINY ((oid)1<<COLTINY_BITS) /* minimum allocation buncnt for a COL */ #define TYPE_void 0 #define TYPE_bit 1 @@ -561,18 +561,10 @@ #define VAR_MAX ((var_t) LLONG_MAX) #endif -typedef oid BUN; /* BUN position */ -#define SIZEOF_BUN SIZEOF_OID -#define BUNFMT OIDFMT -/* alternatively: -typedef size_t BUN; -#define SIZEOF_BUN SIZEOF_SIZE_T -#define BUNFMT SZFMT -*/ -#if SIZEOF_BUN == SIZEOF_INT -#define BUN_NONE ((BUN) INT_MAX) +#if SIZEOF_OID == SIZEOF_INT +#define BUN_NONE ((oid) INT_MAX) #else -#define BUN_NONE ((BUN) LLONG_MAX) +#define BUN_NONE ((oid) LLONG_MAX) #endif #define BUN_MAX (BUN_NONE - 1) /* maximum allowed size of a COL */ @@ -645,10 +637,10 @@ typedef struct { int type; /* type of index entity */ - BUN lim; /* collision list size */ - BUN mask; /* number of hash buckets-1 (power of 2) */ - BUN *hash; /* hash table */ - BUN *link; /* collision list */ + oid lim; /* collision list size */ + oid mask; /* number of hash buckets-1 (power of 2) */ + oid *hash; /* hash table */ + oid *link; /* collision list */ Heap *heap; /* heap where the hash is stored */ } Hash; @@ -662,7 +654,7 @@ * in detail. They are the basic storage unit on which GDK is modelled. * * The COL holds an unlimited number of binary associations, called - * BUNs (@strong{Binary UNits}). The two attributes of a BUN are called + * BUNs (@strong{Binary UNits}). The two attributes of a oid are called * @strong{head} (left) and @strong{tail} (right) in the remainder of this * document. * @@ -671,19 +663,19 @@ * The above figure shows what a COL looks like. It consists of two * columns, called head and tail, such that we have always binary tuples * (BUNs). The overlooking structure is the @strong{COL record}. - * It points to a heap structure called the @strong{BUN heap}. + * It points to a heap structure called the @strong{oid heap}. * This heap contains the atomic values inside the two columns. If they - * are fixed-sized atoms, these atoms reside directly in the BUN heap. If + * are fixed-sized atoms, these atoms reside directly in the oid heap. If * they are variable-sized atoms (such as string or polygon), however, * the columns has an extra heap for storing those (such * @strong{variable-sized atom heaps} are then - * referred to as @strong{Head Heap}s and @strong{Tail Heap}s). The BUN heap then + * referred to as @strong{Head Heap}s and @strong{Tail Heap}s). The oid heap then * contains integer byte-offsets (fixed-sized, of course) into a head- * or tail-heap. * - * The BUN heap contains a contiguous range of BUNs. It starts after + * The oid heap contains a contiguous range of BUNs. It starts after * the @strong{first} pointer, and finishes at the end in the @strong{free} - * area of the BUN. All BUNs after the @strong{inserted} pointer have been + * area of the oid. All BUNs after the @strong{inserted} pointer have been * added in the last transaction (and will be deleted on a transaction * abort). All BUNs between the @strong{deleted} pointer and the @strong{first} * have been deleted in this transaction (and will be reinserted at a @@ -692,7 +684,7 @@ * @- * -- * - * The location of a certain BUN in a COL + * The location of a certain oid in a COL * may change between successive library routine invocations. Therefore, one * should avoid keeping references into the COL storage area for long * periods. @@ -776,10 +768,10 @@ * bit batDirtydesc; // COL descriptor specific dirty flag * Heap* batBuns; // Heap where the buns are stored * // DELTA status - * BUN batDeleted; // first deleted BUN - * BUN batFirst; // empty BUN before the first alive BUN - * BUN batInserted; // first inserted BUN - * BUN batCount; // Tuple count + * oid batDeleted; // first deleted oid + * oid batFirst; // empty oid before the first alive oid + * oid batInserted; // first inserted oid + * oid batCount; // Tuple count * // Head properties * int htype; // Head type number * str hident; // name for head column @@ -789,7 +781,7 @@ * bit hnonil; // head has no nils * oid halign; // alignment OID for head. * // Head storage - * int hloc; // byte-offset in BUN for head elements + * int hloc; // byte-offset in oid for head elements * Heap *hheap; // heap for varsized head values * Hash *hhash; // linear chained hash table on head * // Tail properties @@ -801,7 +793,7 @@ * bit tvarsized; // for speed: tail type is varsized? * oid talign; // alignment OID for head. * // Tail storage - * int tloc; // byte-offset in BUN for tail elements + * int tloc; // byte-offset in oid for tail elements * Heap theap; // heap for varsized tail values * Hash thash; // linear chained hash table on tail * } COL; @@ -853,14 +845,15 @@ unsigned char varsized:1, /* varsized(>0) or fixedsized(0). */ key:2, /* duplicates allowed? */ - dense:1, nonil:1, /* nonil isn't propchecked yet */ + dense:1, + nonil:1, /* nonil isn't propchecked yet */ nil:1, /* nil is set when we found one nil (propcheck) */ unused1:2; oid align; /* OID for sync alignment */ - BUN nosorted_rev; /* position that proves sorted_rev==FALSE */ - BUN nokey[2]; /* positions that prove key ==FALSE */ - BUN nosorted; /* position that proves sorted==FALSE */ - BUN nodense; /* position that proves dense==FALSE */ + oid nosorted_rev; /* position that proves sorted_rev==FALSE */ + oid nokey[2]; /* positions that prove key ==FALSE */ + oid nosorted; /* position that proves sorted==FALSE */ + oid nodense; /* position that proves dense==FALSE */ oid seqbase; /* start of dense head sequence */ Heap heap; /* space for the column. */ @@ -886,11 +879,11 @@ char map_heap; /* mmap mode for atom heap */ /* delta status administration */ - BUN deleted; /* start of deleted elements */ - BUN first; /* to store next deletion */ - BUN inserted; /* start of inserted elements */ - BUN count; /* tuple count */ - BUN capacity; /* tuple capacity */ + oid deleted; /* start of deleted elements */ + oid first; /* to store next deletion */ + oid inserted; /* start of inserted elements */ + oid count; /* tuple count */ + oid capacity; /* tuple capacity */ } COL; typedef struct COLiter { @@ -1024,9 +1017,9 @@ * * @multitable @columnfractions 0.08 0.7 * @item @code{COL* } - * @tab COLnew (int headtype, int tailtype, BUN cap) + * @tab COLnew (int headtype, int tailtype, oid cap) * @item @code{COL* } - * @tab COLextend (COL *b, BUN newcap) + * @tab COLextend (COL *b, oid newcap) * @end multitable * @ * A temporary COL is instantiated using @%COLnew@ with the type aliases of @@ -1042,9 +1035,10 @@ */ #define COLDELETE (-9999) -gdk_export COL *COLnew(int tp, BUN capacity); -gdk_export COL *COLclone(COL *b, BUN capacity); -gdk_export COL *COLextend(COL *b, BUN newcap); +gdk_export COL *COLnew(int tp, oid capacity); +gdk_export COL *COLclone(COL *b, oid capacity); +gdk_export COL *COLextend(COL *b, oid newcap); +gdk_export COL *COLnewdensecol(oid size); /* internal */ gdk_export COL *COLcreatedesc(int tp, int heapnames); @@ -1057,7 +1051,7 @@ * * * - * BUN manipulation + * oid manipulation * ---------------- * * @multitable @columnfractions 0.08 0.7 @@ -1077,22 +1071,22 @@ * @tab BUNdel (COL *b, ptr left, ptr right, bit force) * @item int * @tab BUNdelHead (COL *b, ptr left, bit force) - * @item BUN + * @item oid * @tab BUNfnd (COL *b, ptr head) * @item void - * @tab BUNfndOID (BUN result, COLiter bi, oid *head) + * @tab BUNfndOID (oid result, COLiter bi, oid *head) * @item void - * @tab BUNfndSTD (BUN result, COLiter bi, ptr head) - * @item BUN + * @tab BUNfndSTD (oid result, COLiter bi, ptr head) + * @item oid * @tab BUNlocate (COL *b, ptr head, ptr tail) * @item ptr - * @tab BUNhead (COL *b, BUN p) + * @tab BUNhead (COL *b, oid p) * @item ptr - * @tab BUNtail (COL *b, BUN p) + * @tab BUNtail (COL *b, oid p) * @end multitable * @ * The COLs contain a number of fixed-sized slots to store the binary - * associations. These slots are called BUNs or COL units. A BUN + * associations. These slots are called BUNs or COL units. A oid * variable is a pointer into the storage area of the COL, but it has * limited validity. After a COL modification, previously obtained BUNs * may no longer reside at the same location. @@ -1112,7 +1106,7 @@ * consistency checks, does not update search accelerators, and does * not maintain properties such as the @%hsorted@ and @%tsorted@ flags. Beware! * @ - * The routine @%BUNfnd@ provides fast access to a single BUN providing + * The routine @%BUNfnd@ provides fast access to a single oid providing * a value for the head of the binary association. * A very fast shortcut for @%BUNfnd@ if the selection type is known to be * integer or OID, is provided in the form of the macro @%BUNfndOID@. @@ -1125,20 +1119,20 @@ * side effects on the COL, one should normally copy this value into a * scratch variable for further processing. * - * Behind the interface we use several macros to access the BUN fixed - * part and the variable part. The BUN operators always require a COL pointer - * and BUN identifier. + * Behind the interface we use several macros to access the oid fixed + * part and the variable part. The oid operators always require a COL pointer + * and oid identifier. * @itemize * @item * COLhtype(b) and COLttype(b) find out the head and tail type of a COL. * @item - * BUNfirst(b) returns a BUN pointer to the first BUN as a COL. + * BUNfirst(b) returns a oid pointer to the first oid as a COL. * @item - * BUNlast(b) returns the BUN pointer directly after the last BUN + * BUNlast(b) returns the oid pointer directly after the last oid * in the COL. * @item * BUNhead(b, p) and BUNtail(b, p) return pointers to the - * head-value and tail-value in a given BUN. + * head-value and tail-value in a given oid. * @item * BUNhloc(b, p) and BUNtloc(b, p) do the same thing, but knowing * in advance that the head-atom resp. tail-atom of a COL is fixed size. @@ -1223,23 +1217,23 @@ } else \ ATOMreplace((b)->type, (b)->vheap, (p), v); \ } while (0) -#define fastins_nocheck(b, p, v, s) \ - do { \ - assert((b)->width == (s)); \ - (b)->heap.free += (s); \ - putvalue((b), loc((b), (p)), (v), 0); \ +#define fastins_nocheck(b, p, v, s) \ + do { \ + assert((b)->width == (s)); \ + (b)->heap.free += (s); \ + putvalue((b), COLelement((b), (p)), (v), 0); \ } while (0) _______________________________________________ Checkin-list mailing list [email protected] http://mail.monetdb.org/mailman/listinfo/checkin-list
