Re: [Monetdb-developers] [Monetdb-pf-checkins] pathfinder/modules/pftijah nexi_generate_mil.c, XQuery_0-18, 1.33.2.3, 1.33.2.4
Djoerd Hiemstra wrote:
Update of /cvsroot/monetdb/pathfinder/modules/pftijah In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv1427
Modified Files: Tag: XQuery_0-18 nexi_generate_mil.c Log Message: The ir-model="LM" option was translated to "LMs" in the algebra.
You do realize that the XQuery_0-18 branch is the *old* stable branch and that we're now using XQuery_0-20?
Index: nexi_generate_mil.c
RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/nexi_generate_mil.c,v retrieving revision 1.33.2.3 retrieving revision 1.33.2.4 diff -u -d -r1.33.2.3 -r1.33.2.4 --- nexi_generate_mil.c 15 Jun 2007 08:53:00 -0000 1.33.2.3 +++ nexi_generate_mil.c 4 Oct 2007 13:11:35 -0000 1.33.2.4 @@ -711,7 +711,7 @@ case MODEL_LM :
// MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LM(terms, qenv);\n", com_num, com_nr_left);
MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LMs%s(terms%s,qenv);\n", com_num, com_nr_left, parserCtx->ffPfx, parserCtx->flastPfx);
MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LM%s(terms%s,qenv);\n", com_num, com_nr_left, parserCtx->ffPfx, parserCtx->flastPfx); break;
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 AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-pf-checkins mailing list Monetdb-pf-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
You do realize that the XQuery_0-18 branch is the *old* stable branch and that we're now using XQuery_0-20?
Hi Sjoerd,
Really?? Maybe I should read the developers list more rigorously. BTW why are we sending these mails to the lists?
Best, Djoerd.
Sjoerd Mullender wrote:
Djoerd Hiemstra wrote:
Update of /cvsroot/monetdb/pathfinder/modules/pftijah In directory sc8-pr-cvs16.sourceforge.net:/tmp/cvs-serv1427
Modified Files: Tag: XQuery_0-18 nexi_generate_mil.c Log Message: The ir-model="LM" option was translated to "LMs" in the algebra.
You do realize that the XQuery_0-18 branch is the *old* stable branch and that we're now using XQuery_0-20?
Index: nexi_generate_mil.c
RCS file: /cvsroot/monetdb/pathfinder/modules/pftijah/nexi_generate_mil.c,v retrieving revision 1.33.2.3 retrieving revision 1.33.2.4 diff -u -d -r1.33.2.3 -r1.33.2.4 --- nexi_generate_mil.c 15 Jun 2007 08:53:00 -0000 1.33.2.3 +++ nexi_generate_mil.c 4 Oct 2007 13:11:35 -0000 1.33.2.4 @@ -711,7 +711,7 @@ case MODEL_LM :
// MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LM(terms, qenv);\n", com_num, com_nr_left);
MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LMs%s(terms%s,qenv);\n", com_num, com_nr_left, parserCtx->ffPfx, parserCtx->flastPfx);
MILPRINTF(MILOUT, "R%d := R%d.p_containing_q_LM%s(terms%s,qenv);\n", com_num, com_nr_left, parserCtx->ffPfx, parserCtx->flastPfx); break;
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 AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Monetdb-pf-checkins mailing list Monetdb-pf-checkins@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-pf-checkins
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 AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Monetdb-developers mailing list Monetdb-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-developers
You do realize that the XQuery_0-18 branch is the *old* stable branch and that we're now using XQuery_0-20?
Hi Sjoerd,
Really?? Maybe I should read the developers list more rigorously. BTW why are we sending these mails to the list?
Best, Djoerd.
hej monet-people,
i was a bit puzzled when using the batsize/batdsksize mil-commands on our pf/tijah index BATs:
our pre_size table is also (void|int). however:
(dbl(batsize("tj_DFLT_FT_INDEX_size1")) / count(bat("tj_DFLT_FT_INDEX_size1"))).print(); [ 5.1875055810700283 ]
since this seemed a rather strange size for an entry, i also tried:
(dbl(batdsksize(bat("tj_DFLT_FT_INDEX_size1"))) / count(bat("tj_DFLT_FT_INDEX_size1"))).print(); [ 4.0000030960842796 ]
which looks much more as i expected. but where does the difference come from? even if i copy the bat:
var t := bat("tj_DFLT_FT_INDEX_size1").copy(); (dbl(batsize(t)) / count(t)).print(); [ 5.1875055810700283 ]
the result remains the same. can anyone explain this? the pre_size BAT is usually so large that 25% more space requirement would probably matter.
best -henning
Henning,
batsize and batdsksize give you the actual amount of memory allocated by a BAT which (e.g. due to alignemnent) might be more than the space require to store all the BUNs that the BAT actually/currently holds:
MonetDB>var b := bat(void,int,1000); MonetDB>b.info().reverse().like("batBuns").like("size").print(); #---------------------------------# # h t # name # str str # type #---------------------------------# [ "4000", "batBuns.size" ] [ "4000", "batBuns.maxsize" ] MonetDB>b.count().print(); [ 0 ] MonetDB>b.batsize().print(); [ 8192 ] MonetDB>b.batdsksize().print(); [ 512 ] MonetDB>b.append(1).append(2).append(3); MonetDB>b.info().reverse().like("size").print(); #---------------------------------# # h t # name # str str # type #---------------------------------# [ "1", "hvarsized" ] [ "0", "tvarsized" ] [ "4000", "batBuns.size" ] [ "4000", "batBuns.maxsize" ] MonetDB>b.info().reverse().like("batBuns").like("size").print(); #---------------------------------# # h t # name # str str # type #---------------------------------# [ "4000", "batBuns.size" ] [ "4000", "batBuns.maxsize" ] MonetDB>b.count().print(); [ 3 ] MonetDB>b.batsize().print(); [ 8192 ] MonetDB>b.batdsksize().print(); [ 1024 ]
Hope this helps you further.
Stefan
On Fri, Oct 05, 2007 at 11:14:31AM +0200, Henning Rode wrote:
hej monet-people,
i was a bit puzzled when using the batsize/batdsksize mil-commands on our pf/tijah index BATs:
our pre_size table is also (void|int). however:
(dbl(batsize("tj_DFLT_FT_INDEX_size1")) / count(bat("tj_DFLT_FT_INDEX_size1"))).print(); [ 5.1875055810700283 ]
since this seemed a rather strange size for an entry, i also tried:
(dbl(batdsksize(bat("tj_DFLT_FT_INDEX_size1"))) / count(bat("tj_DFLT_FT_INDEX_size1"))).print(); [ 4.0000030960842796 ]
which looks much more as i expected. but where does the difference come from? even if i copy the bat:
var t := bat("tj_DFLT_FT_INDEX_size1").copy(); (dbl(batsize(t)) / count(t)).print(); [ 5.1875055810700283 ]
the result remains the same. can anyone explain this? the pre_size BAT is usually so large that 25% more space requirement would probably matter.
best -henning
On Thu, Oct 04, 2007 at 09:29:25PM +0200, Djoerd Hiemstra wrote:
You do realize that the XQuery_0-18 branch is the *old* stable branch and that we're now using XQuery_0-20?
Hi Sjoerd,
Really?? Maybe I should read the developers list more rigorously. BTW why are we sending these mails to the lists?
because this mailings (as its name suggests) is THE communication channel for MonetDB developers.
Stefan
Best, Djoerd.
participants (5)
-
Djoerd Hiemstra -
Djoerd Hiemstra -
Henning Rode -
Sjoerd Mullender -
Stefan Manegold