Tim,
In fact, MonetDB is kind of unique in the sense that it *never* does tuple
reconstruction. The low-level APIs tgat receive the result if a query get back
tables, which are still represented as BATs (arrays in which values belonging
to the same tuple are located at the same position).
Othe
bruari 2010 1:34
> To: monetdb-developers@lists.sourceforge.net; Peter Boncz
> Cc: monetdb-check...@lists.sourceforge.net
> Subject: * Re: [Monetdb-checkins] MonetDB/src/gdk gdk_posix.mx, Feb2010,
> 1.176.2.21, 1.176.2.22 gdk_storage.mx, Feb2010, 1.149.2.32, 1.149.2.33
>
> Peter,
&g
). Maybe prefetch sequential
heaps until some limit, like Martin suggests, e.g. 1/4*threads of memory.
Peter
-Original Message-
From: Stefan Manegold [mailto:stefan.maneg...@cwi.nl]
Sent: vrijdag 19 februari 2010 1:34
To: monetdb-developers@lists.sourceforge.net; Peter Boncz
Cc: monetdb
It is correct; thanks!!
On Feb 12, 2010, at 20:22, "Stefan Manegold"
wrote:
> On Fri, Feb 12, 2010 at 07:15:52PM +0100, Stefan Manegold wrote:
>> Peter,
>>
>>> +/* a thread informs it is goin to (preload==1) or stops
>>> (preload==-1) using a range of memory */
>>> void
>>> -MT_mmap_pin(void
o changes or replication.
xquery_shredder.mx just contains the MAL wrappers, uses the M4 shredder API, and
links with ../../runtime/libserialize
Peter
>
> On Tue, Apr 28, 2009 at 2:30 AM, Peter Boncz
> wrote:
> > Update of /cvsroot/monetdb/pathfinder/backends/monet5
> > In dire
8
> gdk_qsort.mx, , 1.34, 1.35 gdk_ssort.mx, , 1.15, 1...
>
> Is this a backward compatible change? In other words, can databases
> created before this change be read by the new version?
>
> I really want backward compatibility, so if it isn't, some kind of
> conversion w
MonetDB developers,
As my Easter contribution, I just checked in changes that introduce a change
in which strings are stored in BATs, that affects only the (not ver often
used?) setting of 64-bits compilation with 32-bits oids. This is achieved
with the configure options --enable-bits=64 --enab
Yes, it actually should.
Sent from my iPhone
On Apr 9, 2009, at 5:42 PM, "Sjoerd Mullender" wrote:
> Peter Boncz wrote:
>> Update of /cvsroot/monetdb/MonetDB/src/gdk
>> In directory 23jxhf1.ch3.sourceforge.com:/tmp/cvs-serv27450
>>
>> Modified Files:
cally the relational algebra
layer.
Peter
> -Original Message-
> From: Martin Kersten [mailto:martin.kers...@cwi.nl]
> Sent: Friday, April 03, 2009 12:42 PM
> To: monetdb-developers@lists.sourceforge.net; Peter Boncz
> Subject: Re: [Monetdb-checkins] MonetDB/src/gdk gdk.mx, , 1
sorry, I was helping Stefan de Konink, but he had a read-only version of the
MonetDB sources.
> -Original Message-
> From: Stefan Manegold [mailto:stefan.maneg...@cwi.nl]
> Sent: Friday, April 03, 2009 1:18 PM
> To: monetdb-developers@lists.sourceforge.net; Peter Boncz
&
Hi,
The mmap method is very costly on Windows as it does not use a virtual
file with holes, but really creates it first. This may also be the
case on macos. However, the pert degradation on Linux is unexpected.
Maybe newer kernels have introduced different behavior.
I think the principle of
You said 5gb on 8gb works better on swap memory.. wow. Maybe go for
100% of ram then for the threshold
Sent from my iPhone
On Feb 19, 2009, at 10:49 PM, "Stefan Manegold"
wrote:
> On Tue, Feb 10, 2009 at 09:13:21AM +, Stefan Manegold wrote:
>> Update of /cvsroot/monetdb/MonetDB/src/gdk
09 23:40
Aan: monetdb-developers@lists.sourceforge.net
CC: Peter Boncz; Sjoerd Mullender
Onderwerp: Re: [Monetdb-checkins] MonetDB/src/gdk gdk_heap.mx,,1.107,1.108
Peter,
IMHO, this check in does more than the log message suggests; among others,
it appears to me as if this check in undoes some fixes
Hi,
(the below analyis of the Stable XQ testweb is not an implicit request for
anybody to do something, I just share it here so you will not do double
work)
Recently I checked in some fixes.
- Because I have the suspicion that certain scripts at NFI may still use
hard commits, I redefined the com
Hi Stefan (the non-german .de one)
> Maybe a very strange idea, could be your better solution. If by default
> these operations are mmap'ed, they should be taken care of by a disk based
> memory extension. Hence being independent of RAM/SWAP but having all pro's
> of both.
You are right. In fact,
Hi Stefan,
Like Martin indicated, MonetDB runs out of memory here, when trying to obtain
a contiguous area of 14GB.
The error messages show that MonetDB is pulling all the stops to try to get
this memory from the system. That is, a so-called "trim" buffer manager thread
tries to unload all unpinn
, October 29, 2008 1:54 PM
To: monetdb-developers@lists.sourceforge.net
Cc: Peter Boncz
Subject: Re: [Monetdb-developers] [Monetdb-checkins]
MonetDB4/src/modules/contrib malalgebra.mx, MonetDB_4-24, 1.8.2.1, 1.8.2.2
Hi Peter et al.
I just did a "quick" check, and propagating the PF_ROX ch
7;s changes
> to the development trunk since they are "PF_ROX-specific" (at least for
> now).
>
> Stefan
>
> > See the results of "Stable" testing (once they are ready later today) to
> > judged whether testing is "desired"/"required"
ender [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2008 9:50 PM
To: monetdb-developers@lists.sourceforge.net
Cc: [EMAIL PROTECTED]
Subject: Re: [Monetdb-checkins] MonetDB4/src/modules/contrib malalgebra.mx,
MonetDB_4-24, 1.8.2.1, 1.8.2.2
On 2008-10-28 20:20, Peter Boncz wrote:
> Hi Sjoerd,
.
Peter
> This type of change is not allowed on a stable branch. Changes of API
> are *not* allowed.
>
> Since we're going to abandon this stable branch soon, I'll let it pass.
>
> On 2008-10-28 18:49, Peter Boncz wrote:
>> Update of /cvsroot/monetdb/MonetDB4/s
netdb-developers@lists.sourceforge.net; Peter Boncz
Subject: Re: [Monetdb-pf-checkins] pathfinder/runtime pathfinder.mx,
,1.421, 1.422 pf_support.mx, , 1.301, 1.302
On Tue, Jun 17, 2008 at 05:07:29PM +0000, Peter Boncz wrote:
> Update of /cvsroot/monetdb/pathfinder/runtime
> In directory s
Hi Stefan, Riham
PF_ROX has the new indexing code, that Lefteris has tried to describe in his
recent paper. This code was only checked for correct operation from MIL in the
code generated by the pf-rox java program of Riham.
The correct operation of the new indexing code when activated automatica
tdb-developers Digest, Vol 22, Issue 4
>
>
> Peter Boncz wrote:
> > Hi Maurice,
> >
> > That is not possible.. without adding extensions such as
> proposed in XQueryP or
> > XQuery-Bang.
> >
> > Why is it that running the update followed by a que
Hi Maurice,
That is not possible.. without adding extensions such as proposed in XQueryP or
XQuery-Bang.
Why is it that running the update followed by a query is not acceptable?
Another idea is to use fn:put() in the update, and then just a HTTP GET to get
the XML result out. That is still a si
Hi,
I read the digests of the monetdb mailing list, which in this case took more
than a month to send me this discussion. That's pretty useless.. I will switch
to immediate mails.
Anyway, Jennie is currently working on getting the repeatable reads transactions
working. This means that by passing
is just
my recommendation *not* to re-enable it.
In M5 nor in M5.
Peter
Dear all,
On Mon, Feb 11, 2008 at 02:54:59PM +0100, Peter Boncz wrote:
> Hi Stefan,
>
> The pftijah bug was unrelated to vmalloc(), a relationship that I never
> assumed.
Indeed, that was (only) my mis-in
ence over X files if encountered). But that also
affects the BBP, the commit protocol.
Peter
Dear all,
On Mon, Feb 11, 2008 at 02:54:59PM +0100, Peter Boncz wrote:
> Hi Stefan,
>
> The pftijah bug was unrelated to vmalloc(), a relationship that I never
> assumed.
Indeed, that w
bigsize(num);
> MonetDB5/src/modules/kernel/status.mx:441: GDK_mem_maxsize =
MAX(GDK_mem_bigsize, sze);
> MonetDB5/src/modules/kernel/status.mx:466: if (sze < GDK_mem_bigsize)
> MonetDB5/src/modules/kernel/status.mx:467: set_mem_bigsize(num);
> MonetDB5/sr
no consequences.
Peter,
What about the consequences in:
build/MonetDB/src/gdk/gdk_heap.c
build/MonetDB5/src/modules/kernel/status.c
build/MonetDB/src/gdk/gdk.h
Peter Boncz wrote:
> Update of /cvsroot/monetdb/MonetDB/src/gdk
> In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-ser
ED]; monetdb-developers@lists.sourceforge.net
> Subject: Re: [Monetdb-developers] [Monetdb-checkins]
> clients/src/mapiclientMapiClient.mx, Clients_1-20, 1.88.2.4, 1.88.2.5
>
>
> Peter Boncz wrote:
> > Hi Niels,
> >
> >> The timing was/is meant for overall quer
vement of the functionality?
best,
Peter
> -Original Message-
> From: Niels Nes [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 21, 2007 12:31 PM
> To: Peter Boncz
> Cc: monetdb-developers@lists.sourceforge.net; [EMAIL PROTECTED]
> Subject: Re: [Monetdb-devel
Hi Sjoerd,
Thanks for fixing some things I was unaware of (empty lines in other languages?)
> The timer is again started when the first line of a query is typed.
> This is the case for *all* languages.
I cannot image cases where it is useful for mclient to keeps stays on someone's
typing speed,
ED]
> Sent: Wednesday, October 17, 2007 1:54 PM
> To: monetdb-developers@lists.sourceforge.net
> Cc: Peter Boncz; Peter Boncz
> Subject: Re: [Monetdb-checkins] MonetDB/src/gdk gdk_atoms.mx,
> MonetDB_1-20, 1.134, 1.134.6.1 gdk_posix.mx, MonetDB_1-20,
> 1.143, 1.143.2.1
>
keep handling certain queries for the time being with mps, but that
> surely is ugly.
>
> Peter
>
> -Original Message-
> From: Keulen, M. van (Maurice) [mailto:[EMAIL PROTECTED]
> Sent: dinsdag 16 oktober 2007 16:38
> To: Peter Boncz [CWI]; Stefan Manegold [CWI]
> Fixing the update issue for Large XML documents)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Dear Peter,
>
>
> Peter Boncz schreef:
> > Thanks for your question, but I regret to inform you that
> your way of
> > communicating
volume of text nodes is likely to be significant).
Peter Boncz
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using
Hi Augustin,
The crash is a bug. You have not told us about your platform (Darwin, I
presume) and whether you have compiled with 64-bits enabled. Considering the
data is 'large', it may be an out-of-memory problem but then in any case it is
a bug, because lack of resources should lead to the query
Hi Djoerd,
All document management functions return the docmgt type, as a mechanism to
ensure that such queries do not perform any document updates.
For MonetDB, this separation is handy, as document management and XQUF
updates rely on two different mechanisms (checkpointing vs WAL) and if
querie
Hi Jennie + Jens,
Jennie, the idea in XRPC is to put the burden of function resolution and
type promotion at the client -- server does nothing, in order to make it
easy to implement XRPC compliant web services in environments that lack any
XPath/XQuery (type analysis) support, such as simple wrapp
: [EMAIL PROTECTED]
Subject: Re: [Monetdb-checkins] MonetDB/src/gdk gdk_utils.mx,1.181,1.182
On 05/09/2007 01:58 PM, Peter Boncz wrote:
> Update of /cvsroot/monetdb/MonetDB/src/gdk
> In directory sc8-pr-cvs16:/tmp/cvs-serv2304
>
> Modified Files:
> gdk_utils.mx
> Log Message:
&
Hi Maurice,
> For my research on probabilistic XML, I need some additional
> functions in XQuery implemented in mil. By means of copying
> code from existing functions in milprint_summer, I've been
> able to get some things working, but I still do not have the
> feeling that I understand the m
Hi Jens,
Thanx.
One correction: we *do* support the upd:put() operator. I is actually named
fn:put(). For the moment, we only accept file URLs. For security reasons,
these must start with a relative path.
Peter
> Update of /cvsroot/monetdb/pathfinder
> In directory sc8-pr-cvs7.sourceforge.net:/
compiler altogether from the runtime, and fork off a process. That also
resolves the MT safeness issue.
Peter
-Original Message-
From: Jan Rittinger [mailto:[EMAIL PROTECTED]
Sent: 22 January 2007 14:04
To: Peter Boncz
Cc: monetdb-developers@lists.sourceforge.net
Subject: Re: [Monetdb
Hi Jan,
As I have indicated, use of the Boehm garbage collector inside the MonetDB
process is not really an option.
If algebra plans can only be compiled with Boehm, than it will become very
difficult to use pathfinder inside MonetDB/XQuery.
Did you try the option with memory sandboxes that at c
44 matches
Mail list logo
