Changeset: 99201b2a3d7c for MonetDB
URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=99201b2a3d7c
Modified Files:
gdk/gdk.h
gdk/gdk_align.c
gdk/gdk_atoms.c
gdk/gdk_atoms.h
gdk/gdk_batop.c
gdk/gdk_batop.mx
gdk/gdk_cbp.c
gdk/gdk_col.c
gdk/gdk_delta.c
gdk/gdk_delta.h
gdk/gdk_logger.c
gdk/gdk_rangejoin.mx
gdk/gdk_relop.mx
gdk/gdk_scanselect.mx
gdk/gdk_scanselect_defs.mx
gdk/gdk_search.c
gdk/gdk_search.h
gdk/gdk_setop.mx
gdk/gdk_storage.c
gdk/gdk_tm.c
gdk/gdk_utils.c
monetdb5/modules/kernel/column.mx
Branch: headless
Log Message:
Changed type BUN to oid, converted (most of) gdk_batop to using COL.
Also created new function COLnewdensecol.
diffs (truncated from 8737 to 300 lines):
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.
@@ -1234,12 +1228,12 @@
assert((b)->width == (vs)); \
(b)->heap.free += (vs); \
putvalue((b), loc((b), (p)), (v), 0); \
- (b)->count++; \
+ (b)->count++; \
} while (0) \
#define bunfastins(b, v) \
do { \
- register BUN _p = BUNlast(b); \
+ register oid _p = BUNlast(b); \
if (_p == BUN_MAX || COLcount(b) == BUN_MAX) { \
GDKerror("bunfastins: bat too large\n"); \
goto bunins_failed; \
@@ -1267,20 +1261,20 @@
gdk_export COL *COLins(COL *b, COL *c, bit force);
gdk_export COL *COLappend(COL *b, COL *c, bit force);
gdk_export COL *BUNdel(COL *b, ptr p, bit force);
-gdk_export BUN BUNdelete(COL *b, BUN p, bit force);
+gdk_export oid BUNdelete(COL *b, oid p, bit force);
gdk_export COL *COLdel(COL *b, COL *c, bit force);
-gdk_export COL *BUNinplace(COL *b, BUN p, ptr h, bit force);
+gdk_export COL *BUNinplace(COL *b, oid p, ptr h, bit force);
gdk_export COL *COLreplace(COL *b, COL *n, bit force);
_______________________________________________
Checkin-list mailing list
[email protected]
http://mail.monetdb.org/mailman/listinfo/checkin-list
