- developers-list - monetdb.org

[Monetdb-developers] Large quantity Telecom products with low price
by Jun Wang 13 Aug '05

13 Aug '05

We supply large quantity low price Telecom products: Fiber optic jumper, UTP Cat5e cable, patch cable, USB cable, Phone cable and various Telecom components. Welcome OEM order and Custom cable. Details pay a visit to: www.sgetek.com. Download our catalogue from: www.sgetek.com/order.asp. Please contact with us by: prestonsh(a)126.com for our newest price list. Jun Wang SGETEK SHANGHAI CO., LIMITED SGETEK UK CO., LIMITED TEL:+86 21 67820784 FAX:+86 21 67820791 ---------------------------------------------------------------------- If no use for you send a "No Thanks" mail to: cable88(a)163.com, your mail will be deleted from our list within 2 working days.

1 0

[Monetdb-developers] Re: [Monetdb-checkins] MonetDB/src/modules/plain pcre.mx,1.14,1.15
by Fabian 10 Aug '05

10 Aug '05

Sjoerd Mullender wrote: > Update of /cvsroot/monetdb/MonetDB/src/modules/plain > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22873 > > Modified Files: > pcre.mx > Log Message: > Do not put anything above the license text (except possibly a > "hash-bang" line (#!/...)). The script that updates the license text > does not like this. > > Furthermore, the standard in the MonetDB code is to use 8-space tabs. > If you want to view things differently, that's fine, but make at least > sure that it still looks correctly with 8-space tabs. Since when? I have been told 4 width *tabs* (not spaces) is the standard in the MonetDB project. You seem to suggest here that I should use spaces instead... Off-topic: is there anyone who actually uses 8 width tabs within vi?

2 1

[Monetdb-developers] max size of a bat
by Peter Boncz 04 Aug '05

04 Aug '05

Folks, MIN(2G, 4GB/sizeof(type)) is indeed the maximum number of elements in a BAT for 32-bits systems. Obviously, for 64-bits operating systems, no such restriction exists. Peter

1 0

[Monetdb-developers] Re: [MonetDB-users] speed comparison off inserts and deletes, and db size question
by Joel Reymont 03 Aug '05

03 Aug '05

On Aug 3, 2005, at 10:40 AM, Fabian wrote: > You should keep in mind that if you use a (V)OID on an 32-bits > platform, that you have a limitation of the number of rows that you > can contain in a BAT. Also, and OID cannot be bigger than the int > it is, so if you do need more rows, or sequence numbers that are > higher, you will have to jump over to lng and do the sequence > numbers yourself or something. > Is it 2^32-1 for the maximum number of rows in a BAT? > You can never join BATs that are bigger than max(OID), so you have > to play tricks like doing the selects on all it's subparts and then > unioning the results, given they are small enough to be stored in > one BAT. > Are you referring to BAT * BATkunion (BAT *b, BAT *c) in the kernel guide? I assume that I need to use BATkunion as opposed to BATsunion since I'm looking only at the head column. And that the fragments satisfy the set property since they are fragments of a larger BAT with a non- repeating oid range. Am I thinking right? Do I need to set any properties on the BAT for the union to work? Thanks, Joel -- http://wagerlabs.com/uptick

3 2

[Monetdb-developers] Re: [MonetDB-users] speed comparison off inserts and deletes, and db size question
by Joel Reymont 03 Aug '05

03 Aug '05

On Aug 3, 2005, at 10:40 AM, Fabian wrote: > > Most of the common MIL operators have C equivalents, like BATnew, > BATcount, etc. Right, I realize that. And that the extension modules are backed by C code as well. > You should keep in mind that if you use a (V)OID on an 32-bits > platform, that you have a limitation of the number of rows that you > can contain in a BAT. Also, and OID cannot be bigger than the int > it is, so if you do need more rows, or sequence numbers that are > higher, you will have to jump over to lng and do the sequence > numbers yourself or something. Is it 2^32-1 for the maximum number of rows in a BAT? > You can never join BATs that are bigger than max(OID), so you have > to play tricks like doing the selects on all it's subparts and then > unioning the results, given they are small enough to be stored in > one BAT. Are you referring to BAT * BATkunion (BAT *b, BAT *c) in the kernel guide? I assume that I need to use BATkunion as opposed to BATsunion since I'm looking only at the head column. And that the fragments satisfy the set property since they are fragments of a larger BAT with a non- repeating oid range. Am I thinking right? Do I need to set any properties on the BAT for the union to work? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Splicing vertically fragmented BATs
by Joel Reymont 03 Aug '05

03 Aug '05

Folks, What series of GDK operations (possibly with module extensions) can I use to splice a vertically fragmented BAT? I'm looking to do this in C/C++ as opposed to MIL. Thanks in advance, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] X100
by Joel Reymont 02 Aug '05

02 Aug '05

Is it possible to look at the X100 source code or more detailed information right now? What I'm trying to accomplish is basically the same, in Common Lisp. I read through Peter Boncz's Ph.D. thesis as well as the X100 paper. One thing that I don't understand is whether the X100 scan retrieves vectors from _all_ participating BATs. I'm also wondering how the size of the cache (and thus the size of the vector) is determined. Thanks, Joel -- http://wagerlabs.com/uptick

2 3

[Monetdb-developers] Deleting and inserting BUNs. What happens?
by Joel Reymont 01 Aug '05

01 Aug '05

Folks, According to Peter's Ph. D. thesis I need to keep track of deleted (and inserted?) BUNs in [void, ...] BATs since the head is densely packed. Do I still need to do that and what happens when BUNs are deleted and inserted in [oid, ...] BATs? Thanks, Joel -- http://wagerlabs.com/uptick

1 0

[Monetdb-developers] Re: X100
by Peter Boncz 30 Jul '05

30 Jul '05

Hi Joel, About X100. In my opinion this is a very cool project that actually constitutes an entirely new query engine. It is more scalable than the current Monet4 engine, and also than the Monet5 engine. There is no main memory limitation anymore. Let's think about it as Monet6 (though that is not sure). The system is quite functional, but especially regarding APIs, database updates and also binary/source distribution of the code, a lot has to be done. Currently, we are concentrating on obtaining scientific results. Some functioanlities (like database updates) still have to be developed. I think we are more than a year off from a releasable system. Also, it has not been decided yet whether that will be an open-source release. Maybe X100 has some commercial future.. Then more general. I just read your posts on this mailing list and I do not have a full grasp of your plans in order to properly advise you. Some general tips: - try to keep all bulk operations in MIL, with interfaces to the lisp engine that move only little data in and out. - use unary bats preferable. i/e/ those that have a void head type - try to seperate data and metadata. Thus, the schema you use, and also the results, are best kept outside MonetDB. Maybe store them in flat files XML or something. It makes the architecture easier to maintain. Also, your application does not depend that strongly on MonetDB repositories. As for special purpose indexing, often it is possible to represent them as a set of bats. you will have to do some coding in a new monet extension module (a .mx file as found in the src/modules/plain/ directory) to write some primitives that access those bats (that are your index) efficiently. just my 2 cts. Peter

2 1

Re: [Monetdb-developers] enum BATs
by Joel Reymont 29 Jul '05

29 Jul '05

Martin, Thanks for your help and my apologies. I thought there was support for enums in the GDK but I'll take a look at the enum module. I'm trying to implement the pieces of MIL that I need for my trading platform, in Common Lisp. Thanks, Joel On Jul 29, 2005, at 11:52 PM, Martin Kersten wrote: > Joel, > > We apologize that the user-documentation is behind the code. > Nevertheless, the following areas are a good starting point for > gaining additional information. -- http://wagerlabs.com/uptick

1 0