Update of /cvsroot/monetdb/MonetDB/src/gdk
In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv14868/src/gdk
Modified Files:
gdk.mx gdk_align.mx gdk_bat.mx gdk_batop.mx gdk_bbp.mx
gdk_heap.mx gdk_logger.mx gdk_rangejoin.mx
gdk_scanselect_defs.mx
Log Message:
propagated changes of Sunday Feb 03 2008 - Friday Feb 08 2008
from the MonetDB_1-22 branch to the development trunk
Index: gdk_logger.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_logger.mx,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -d -r1.14 -r1.15
--- gdk_logger.mx 1 Feb 2008 12:21:37 -0000 1.14
+++ gdk_logger.mx 8 Feb 2008 22:35:06 -0000 1.15
@@ -18,7 +18,7 @@
@t Transactions
@a N. J. Nes
@v 2.0
[EMAIL PROTECTED]
+
@* Introduction
In the philosophy of MonetDB, transaction management overhead should only
be paid when necessary. Transaction management is for this purpose
@@ -32,7 +32,7 @@
The logger uses a directory to store its log files. One master log file
stores information about the version of the logger and the transaction
log files. This file is a simple ascii file with the following format:
- 6DIGIT-VERSION\n[log file number \n]*]*
+ @code{6DIGIT-VERSION\n[log file number \n]*]*}
The transaction log files have a binary format, which stores fixed size
logformat headers (flag,nr,bid), where the flag is the type of update logged.
The nr field indicates how many changes there were (in case of
inserts/deletes).
Index: gdk.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk.mx,v
retrieving revision 1.249
retrieving revision 1.250
diff -u -d -r1.249 -r1.250
--- gdk.mx 5 Feb 2008 15:19:02 -0000 1.249
+++ gdk.mx 8 Feb 2008 22:35:05 -0000 1.250
@@ -17,9 +17,9 @@
@f gdk
@t The Goblin Database Kernel
@v Version 3.05
[EMAIL PROTECTED] Martin L. Kersten & Peter Boncz & Niels Nes
[EMAIL PROTECTED] Martin L. Kersten, Peter Boncz, Niels Nes
[EMAIL PROTECTED] The Inner Core
[EMAIL PROTECTED] The Inner Core
The innermost library of the MonetDB database system is formed by
the library called GDK, an abbreviation of Goblin Database Kernel.
Its development was originally rooted in the design of a pure
@@ -86,9 +86,9 @@
[EMAIL PROTECTED]
@end tex
. A BAT is a
-self-descriptive main-memory structure that represents the @strong{binary
-relationship} between two atomic types.
-@
+self-descriptive main-memory structure that represents the
[EMAIL PROTECTED] relationship} between two atomic types.
+
The association can be defined over:
@table @code
@item void:
@@ -124,7 +124,6 @@
Bat descriptor. This allows for recursive adminstered tables, but
severely complicates transaction management. Therefore, they
CAN ONLY BE STORED IN TRANSIENT BATs.
-[on the list to become depreciated,
@end table
This model can be used as a back-end model underlying other -higher
@@ -162,7 +161,7 @@
@end tex
. Alternatively, when the table is sorted, it will resort to merge-scan
operations or binary lookups.
-@
+
BATs are built on the concept of heaps, which are large pieces of main
memory. They can also consist of virtual memory, in case the working
set exceeds main-memory. In this case, GDK supports operations that
@@ -171,7 +170,6 @@
@- Rationale
-
The rationale for choosing a BAT as the building block for both
relational and object-oriented system is based on the following
observations:
@@ -211,7 +209,7 @@
@item -
Object-oriented systems often maintain a double cache, one with the
disk-based representation and a C pointer-based main-memory structure.
-This causes expensive conversions and replicated storage management.\\
+This causes expensive conversions and replicated storage management.
GDK does not do such `pointer swizzling'. It used virtual-memory
(@strong{mmap()}) and buffer management advice (@strong{madvise()}) OS
primitives to
cache only once. Tables take the same form in memory as on disk,
@@ -293,7 +291,6 @@
and relational operators. They are implemented in terms of BAT- and
BUN-manipulation GDK primitives.
@end table
-@
@+ Interface Files
In this section we summarize the user interface to the GDK library.
@@ -450,7 +447,7 @@
@item int
@tab GDKexit (int status)
@end multitable
-@
+
The session is bracketed by @%GDKinit@ and @[EMAIL PROTECTED] Initialization
involves
setting up the administration for database access, such as memory allocation
for the database buffer pool.
@@ -712,7 +709,7 @@
referred to as @strong{Head Heap}s and @strong{Tail Heap}s). The BUN 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 @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
@@ -726,7 +723,7 @@
may change between successive library routine invocations. Therefore, one
should avoid keeping references into the BAT storage area for long
periods.
-@
+
Passing values between the library routines and the enclosing C
program is primarily through value pointers of type @[EMAIL PROTECTED] Pointers
into the BAT storage area should only be used for retrieval. Direct
@@ -788,10 +785,9 @@
@}
@- The BAT record
-
The elements of the BAT structure are introduced in the remainder.
Instead of using the underlying types hidden beneath it, one should
-use a @%BAT@ type that is supposed to look like this:
+use a @emph{BAT} type that is supposed to look like this:
@verbatim
typedef struct {
/* static BAT properties */
@@ -1023,7 +1019,6 @@
@item int
@tab
HEAPwarm (Heap *h);
[EMAIL PROTECTED] int
@end multitable
@
@@ -1051,13 +1046,13 @@
@table @code
@item void
-HEAP_initialize (Heap* h, size\_t nbytes, size\_t nprivate, int align )
+HEAP_initialize (Heap* h, size_t nbytes, size_t nprivate, int align )
@item void
HEAP_destroy (Heap* h)
@item int
-HEAP_malloc (Heap* heap, size\_t nbytes)
+HEAP_malloc (Heap* heap, size_t nbytes)
@item void
-HEAP_free (Heap *heap, size\_t block)
+HEAP_free (Heap *heap, size_t block)
@item int
HEAP_private (Heap* h)
@item void
@@ -1560,7 +1555,7 @@
MonetDB now has a mmap trim thread that takes care of flushing the
memory mapped regions when MonetDB starts to consume too much
main memory. Heaps (that are randomly accessed) can be excluded
-from this mechanism, by pinning them. BATmmap\_pin/unpin do
+from this mechanism, by pinning them. BATmmap_pin/unpin do
this for all heaps of a BAT.
@- Heap Storage Modes
@@ -1687,6 +1682,8 @@
@h
#define GDK_SORTED_REV 128 /* reversely sorted */
#define GDK_SORTED 65 /* 65 = (32 bits radix_clustered)<<1 + 1 */
+#define REVERT_SORTED(o) \
+ o==GDK_SORTED?GDK_SORTED_REV:(o==GDK_SORTED_REV?GDK_SORTED:0)
gdk_export BAT *BATsort(BAT *b);
gdk_export BAT *BATsort_rev(BAT *b);
@@ -2665,8 +2662,8 @@
by doing BATabort on all persistent bats.
BUG: after a failed @%TMcommit@, @%TMabort@ does not do anything
-because @%TMcommit@ does the @[EMAIL PROTECTED] *before* attempting to
-sync to disk instead of *after& doing this.
+because @%TMcommit@ does the @[EMAIL PROTECTED] @emph{before} attempting to
+sync to disk instead of @sc{after} doing this.
The previous state can also be queried. @%BATprev@ is a view
on the current BAT as it was in the previous state. @%BATalpha@
@@ -2696,10 +2693,10 @@
@tab ALIGNrelated (BAT *b1, BAT *b2)
@item int
@tab ALIGNsetH ((BAT *dst, BAT *src)
-\hline
+
@item BAT *
@tab BATpropcheck (BAT *b, int mode)
-\hline
+
@item BAT*
@tab VIEWcreate (BAT *h, BAT *t)
@item int
@@ -2715,7 +2712,7 @@
@item BAT*
@tab VIEWreset (BAT *b)
@item BAT*
[EMAIL PROTECTED] BATmaterialize (BAT *b, size\_t size)
[EMAIL PROTECTED] BATmaterialize (BAT *b, size_t size)
@end multitable
@
Alignments of two columns of a BAT means that the system knows
@@ -2955,9 +2952,9 @@
@verbatim
void
-print_books(BAT *author\_books, str author)
+print_books(BAT *author_books, str author)
{
- BAT *b = author\_books;
+ BAT *b = author_books;
size_t i;
printf("%s\n==================\n", author);
@@ -3151,18 +3148,18 @@
@- BAT relational operators
@multitable @columnfractions 0.08 0.7
@item BAT *
[EMAIL PROTECTED] BATjoin (BAT *l, BAT *r, size\_t estimate)
[EMAIL PROTECTED] BATjoin (BAT *l, BAT *r, size_t estimate)
@item BAT *
[EMAIL PROTECTED] BATouterjoin (BAT *l, BAT *r, size\_t estimate)
[EMAIL PROTECTED] BATouterjoin (BAT *l, BAT *r, size_t estimate)
@item BAT *
[EMAIL PROTECTED] BATthetajoin (BAT *l, BAT *r, int mode, size\_t estimate)
[EMAIL PROTECTED] BATthetajoin (BAT *l, BAT *r, int mode, size_t estimate)
@item BAT *
@tab BATsemijoin (BAT *l, BAT *r)
@item BAT *
@tab BATselect (BAT *b, ptr tl, ptr th)
@item BAT *
@tab BATfragment (BAT *b, ptr l, ptr h, ptr L, ptr H)
[EMAIL PROTECTED] \hline
[EMAIL PROTECTED]
@item BAT *
@tab BATsunique (BAT *b)
@item BAT *
Index: gdk_bbp.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_bbp.mx,v
retrieving revision 1.209
retrieving revision 1.210
diff -u -d -r1.209 -r1.210
--- gdk_bbp.mx 5 Feb 2008 15:19:03 -0000 1.209
+++ gdk_bbp.mx 8 Feb 2008 22:35:06 -0000 1.210
@@ -25,13 +25,13 @@
The BBP is a directory which contains status information about all known BATs.
This interface may be used very heavily, by data-intensive applications.
To eliminate all overhead, read-only access to the BBP may be done by
-table-lookups. The integer index type for these lookups is @%bat@, as
-retrieved by @%BBPcacheid(b)@. The @%bat@ zero is reserved for the nil bat.
+table-lookups. The integer index type for these lookups is @emph{bat}, as
+retrieved by @emph{BBPcacheid(b)}. The @emph{bat} zero is reserved for the nil
bat.
@item persistence
The BBP is made persistent by saving it to the dictionary file
called @emph{BBP.dir} in the database. The dictionary can always be
-reconstructed from the @emph{ .desc} files. Its main role is to
+reconstructed from the @emph{.desc} files. Its main role is to
speed-up system restart, because now it requires just a few IOs
instead of a complete directory scan and reading all descriptors
to find all BATs.
@@ -257,15 +257,15 @@
@table @code
@item GDKcacheLock]
this lock guards the free slot management in the BBP array. The BBP
-operations that allocate a new slot for a new BAT (@%BBPinit@,@%BBPcacheit@),
-delete the slot of a destroyed BAT (@%BBPreclaim@), or rename a BAT
-(@%BBPrename@), hold this lock. It also protects all BAT (re)naming actions
+operations that allocate a new slot for a new BAT
(@emph{BBPinit},@emph{BBPcacheit}),
+delete the slot of a destroyed BAT (@emph{BBPreclaim}), or rename a BAT
+(@emph{BBPrename}), hold this lock. It also protects all BAT (re)naming
actions
include (read and write) in the hash table with BAT names.
@item GDKswapLock
this lock guards the swap (loaded/unloaded) status of the BATs. Hence, all
BBP routines that influence the swapping policy, or actually carry out the
-swapping policy itself, acquire this lock (e.g. @%BBPfix@,@%BBPunfix@).
-Note that this also means that updates to the BBP\_status indicator array
+swapping policy itself, acquire this lock (e.g. @emph{BBPfix},@emph{BBPunfix}).
+Note that this also means that updates to the BBP_status indicator array
must be protected by GDKswapLock.
To reduce contention GDKswapLock was split into multiple locks; it is now
@@ -282,7 +282,7 @@
operations may be ongoing while at the same time at most one BBP write
operation @strong{on a different BAT} is executing.
This holds for accesses to the public (quasi-)
-arrays @%BBPcache@, @%BBPstatus@, @%BBPrefs@, @%BBPlogical@ and @[EMAIL
PROTECTED] These
+arrays @emph{BBPcache}, @emph{BBPstatus}, @emph{BBPrefs}, @emph{BBPlogical}
and @emph{BBPphysical}. These
arrays are called quasi as now they are actually stored together in one big
BBPrec
array called BBP, that is allocated in anonymous VM space, so we can
reallocate
this structure without changing the base address (a crucial feature if read
@@ -1786,7 +1786,7 @@
@item
while decisions are made as to which bats to unload (1) the BBP is
scanned, and (2) unload decisions are made. Due to these properties,
-the search\&decide phase of BBPtrim acquires both GDKcacheLock (due to (1))i
+the search&decide phase of BBPtrim acquires both GDKcacheLock (due to (1))
and all GDKswapLocks (due to (2)). They must be released during the actual
unloading. (as otherwise deadlock occurs => unloading a bat may e.g. kill
an accelerator that is a BAT, which in turn requires BBP lock acquisition).
@@ -1794,7 +1794,7 @@
to avoid further deadlock, the update functions in BBP that hold either
GDKcacheLock or a GDKswapLock may never cause a BBPtrim (notice that BBPtrim
could theoretically be set off just by allocating a little piece of memory,
e.g.
-GDKstrdup()). If these routines must alloc memory, they must set the
BBP\_notrim
+GDKstrdup()). If these routines must alloc memory, they must set the
BBP_notrim
variable, acquiring the addition GDKtrimLock, in order to prevent such
deadlock.
@item
the BBPtrim is atomic; only releases its locks when all BAT unload
@@ -1814,7 +1814,7 @@
We also refined the swap criterion. If the BBPtrim was initiated due to:
- too much descriptors: small bats are unloaded first (from LRU cold to hot)
- too little memory: big bats are unloaded first (from LRU cold to hot).
-Unloading-first is enforced by subtracting $2^31$ from the stamp in the
+Unloading-first is enforced by subtracting @math{2^31} from the stamp in the
field where the candidates are sorted on.
@{
@c
@@ -2185,7 +2185,6 @@
@}
@+ Small BAT Cache
[EMAIL PROTECTED]
PETER: rewrote the batcache to make it stable with views and actually faster
than allocating new bats (I guess that was the purpose of it)
@@ -2205,13 +2204,13 @@
and then benchmark the d*mn thing (also missing in the previous exercise) :
-module(alarm);
-bbp_batcache_minsize(wrd(256));
-{ var t := time(), i := 0; while((i :+= 1) < 100000) bat(int,int);
print(time() - t); }
-[ 490 ]
-bbp_batcache_minsize(wrd(0));
-{ var t := time(), i := 0; while((i :+= 1) < 100000) bat(int,int);
print(time() - t); }
-[ 847 ]
+ module(alarm);
+ bbp_batcache_minsize(wrd(256));
+ @{ var t := time(), i := 0; while((i :+= 1) < 100000) bat(int,int);
print(time() - t); @}
+ [ 490 ]
+ bbp_batcache_minsize(wrd(0));
+ @{ var t := time(), i := 0; while((i :+= 1) < 100000) bat(int,int);
print(time() - t); @}
+ [ 847 ]
so with caching *some* MIL programs can be nearly twice as fast (optimized
compile),
though I expect the gains to be smaller in general.
@@ -2753,7 +2752,7 @@
It is now locked, to get proper file counters, and also to prevent
concurrent BBPrecovers, etc.
[EMAIL PROTECTED]
+
backup_dir == 0 => no backup BBP.dir
backup_dir == 1 => BBP.dir saved in BACKUP/
backup_dir == 2 => BBP.dir saved in SUBCOMMIT/
Index: gdk_batop.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_batop.mx,v
retrieving revision 1.150
retrieving revision 1.151
diff -u -d -r1.150 -r1.151
--- gdk_batop.mx 1 Feb 2008 12:21:35 -0000 1.150
+++ gdk_batop.mx 8 Feb 2008 22:35:05 -0000 1.151
@@ -1681,31 +1681,36 @@
return NULL;
}
ALIGNdel(b, "BATrevert", FALSE);
- hs = (size_t) Hsize(b);
- ts = (size_t) Tsize(b);
- h = (char *) GDKmalloc(hs);
- t = (char *) GDKmalloc(ts);
- if (!h || !t) {
+ if ((hs = (size_t) Hsize(b)) > 0) {
+ h = (char *) GDKmalloc(hs);
+ if (!h) {
+ return NULL;
+ }
+ for (p = BUNlast(b)?BUNlast(b) - 1:0, q = BUNfirst(b); p > q;
p--, q++){
+ char *ph = BUNhloc(bi,p);
+ char *qh = BUNhloc(bi,q);
+
+ memcpy(h , ph, hs);
+ memcpy(ph, qh, hs);
+ memcpy(qh, h , hs);
+ }
GDKfree(h);
- GDKfree(t);
- return NULL;
}
- for (p = BUNlast(b)?BUNlast(b) - 1:0, q = BUNfirst(b); p > q; p--, q++){
- char *ph = BUNhloc(bi,p);
- char *qh = BUNhloc(bi,q);
- char *pt = BUNtloc(bi,p);
- char *qt = BUNtloc(bi,q);
-
- memcpy(h , ph, hs);
- memcpy(ph, qh, hs);
- memcpy(qh, h , hs);
+ if ((ts = (size_t) Tsize(b)) > 0) {
+ t = (char *) GDKmalloc(ts);
+ if (!t) {
+ return NULL;
+ }
+ for (p = BUNlast(b)?BUNlast(b) - 1:0, q = BUNfirst(b); p > q;
p--, q++){
+ char *pt = BUNtloc(bi,p);
+ char *qt = BUNtloc(bi,q);
- memcpy(h , pt, ts);
- memcpy(pt, qt, ts);
- memcpy(qt, h , ts);
+ memcpy(t , pt, ts);
+ memcpy(pt, qt, ts);
+ memcpy(qt, t , ts);
+ }
+ GDKfree(t);
}
- GDKfree(h);
- GDKfree(t);
HASHdestroy(b);
if (b->hsorted & GDK_SORTED)
b->hsorted = GDK_SORTED_REV;
Index: gdk_rangejoin.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_rangejoin.mx,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- gdk_rangejoin.mx 5 Feb 2008 15:19:03 -0000 1.8
+++ gdk_rangejoin.mx 8 Feb 2008 22:35:06 -0000 1.9
@@ -29,24 +29,28 @@
#include "gdk.h"
@- BAT range and band join operators
-@
The @%BATbandjoin@ produces the associations [A, D] such that S.C-c1 <=
R.b <= S.C + c2. The special case c1 = 0 and c2 = infinite leads to a
thetajoin.
@h
gdk_export BAT *BATrangejoin(BAT *l, BAT *rl, BAT *rh, bit li, bit hi);
-/* Join all BUNs of the BATs that have tail values: {rl <= l <= rh}. */
+@
+Join all BUNs of the BATs that have tail values: {rl <= l <= rh}.
[EMAIL PROTECTED]
gdk_export BAT *BATbandjoin(BAT *l, BAT *r, ptr mnus, ptr plus, bit li, bit
hi);
-/* Join all BUNs of the BATs that have tail values: {r-mnus <= l <= r+plus}. */
+@
+Join all BUNs of the BATs that have tail values: {r-mnus <= l <= r+plus}.
[EMAIL PROTECTED]
#endif /* GDK_RANGEJOIN_H */
@c
#include "monetdb_config.h"
#include "gdk_rangejoin.h"
[EMAIL PROTECTED]
BAT *BATrangejoin(BAT *l, BAT *rl, BAT *rh, bit li, bit hi)
{
BAT *bn;
@@ -214,8 +218,6 @@
return bn;
}
-
-@
@}
@-
The easiest case is to implement a nested loop for band operations.
@@ -254,7 +256,6 @@
@:bandjoin_nl_(@1,>,<)
break;
@
[EMAIL PROTECTED]
@= bandjoin_mj_loop
/* sliding window like solution */
@@ -404,3 +405,4 @@
BBPreclaim(r);
return bn;
}
[EMAIL PROTECTED]
Index: gdk_align.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_align.mx,v
retrieving revision 1.90
retrieving revision 1.91
diff -u -d -r1.90 -r1.91
--- gdk_align.mx 1 Feb 2008 12:21:33 -0000 1.90
+++ gdk_align.mx 8 Feb 2008 22:35:05 -0000 1.91
@@ -31,9 +31,9 @@
This operation will mark both columns of the first @emph{BAT} as synced with
the second (likewise, @emph{BATcopy()}, which makes a copy, instead of
in-place
shuffling, has the same alignment effect, @emph{BATmark()} marks the tail
column
-as synced with the head of the original @emph{BAT}, and for instance
[EMAIL PROTECTED]()} marks both return columns as aligned with its left
parameter).
-@
+as synced with the head of the original @emph{BAT}, and for
+instance @emph{BATsemijoin()} marks both return columns as aligned with its
left parameter).
+
Each alignment sequence is given a unique identifier, so as to easily
detect this situation. It is retained in the @emph{BAT descriptor}.
@+ Alignment Design Considerations
@@ -52,7 +52,7 @@
Alignment statuses must be
kept consistent under database commits and aborts.
@end itemize
-@
+
As for performance, the most important observation to make is that
operations that do not need alignment, will suffer most from
overheads introduced in the BUN update mechanism. For this reason,
@@ -192,11 +192,11 @@
BAT is @emph{VIEWcreate}. On this @emph{#read-only} BAT (there is kernel
support for this), you can then make vertical slices.
Use @emph{VIEWhead} for this.
-@
+
It is possible to create a view on a writable BAT. Updates
in the parent are then automatically reflected in the VIEW.
Note that the VIEW bat itself can never be modified.
-@
+
Horizontal views should only be given out on a view BAT, but
only if it is dead sure the parent BAT is read-only.
This because they cannot physically share the batBuns heap
Index: gdk_heap.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_heap.mx,v
retrieving revision 1.93
retrieving revision 1.94
diff -u -d -r1.93 -r1.94
--- gdk_heap.mx 1 Feb 2008 12:21:36 -0000 1.93
+++ gdk_heap.mx 8 Feb 2008 22:35:06 -0000 1.94
@@ -497,7 +497,7 @@
As we do not (yet) want to change the BAT image on disk, This is now fixed by
switching on-the-fly between two representations. We ensure that the 64-bit
memory
representation is just as long as the 32-bits version (20 bytes) so the rest
of
-the heap never needs to shift. The function HEAP\_checkformat converts at load
+the heap never needs to shift. The function HEAP_checkformat converts at load
time dynamically between the layout found on disk and the memory format.
Recognition of the header mode is done by looking at the first two ints:
alignment must be 4 or 8, and head can never be 4 or eight.
Index: gdk_scanselect_defs.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_scanselect_defs.mx,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- gdk_scanselect_defs.mx 11 Jan 2008 10:37:00 -0000 1.2
+++ gdk_scanselect_defs.mx 8 Feb 2008 22:35:06 -0000 1.3
@@ -32,6 +32,7 @@
calls to these functions.
@c
[EMAIL PROTECTED]
@- The actual BAT_scanselect
@= seqscanPrologue
@@ -300,3 +301,5 @@
@c
@:DEFseqscanTTget(c)@
@-
+
[EMAIL PROTECTED]
Index: gdk_bat.mx
===================================================================
RCS file: /cvsroot/monetdb/MonetDB/src/gdk/gdk_bat.mx,v
retrieving revision 1.187
retrieving revision 1.188
diff -u -d -r1.187 -r1.188
--- gdk_bat.mx 1 Feb 2008 12:21:35 -0000 1.187
+++ gdk_bat.mx 8 Feb 2008 22:35:05 -0000 1.188
@@ -2268,7 +2268,7 @@
Thus we cannot modify the hp->storage fields, but rather store the new modes
in special
batMap fields that are used when the BAT descriptor is saved.
-This makes the BATmmap safer \& simpler as it is now
+This makes the BATmmap safer & simpler as it is now
incorporated in the normal bat loading and saving mechanism.
It also makes the mmap faster as when through caching you
@@ -2476,8 +2476,8 @@
goto (1)
@end multitable
-Now we see that for BBPsync (heap\_move) it is sufficient to check for the
.priv
-suffix to determine the appropriate backup\_bat behavior (i.e. register a X
.killfile
+Now we see that for BBPsync (heap_move) it is sufficient to check for the .priv
+suffix to determine the appropriate backup_bat behavior (i.e. register a X
.killfile
anticipating the write(X) besides a X.priv).
HEAPsave: we do not need to worry about saving readonly bats: as we save them
in
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-checkins mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-checkins
