Bugs item #2716723, was opened at 2009-03-27 11:40
Message generated for change (Comment added) made by boncz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2716723&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: PF/compiler
Group: Pathfinder CVS Head
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wouter Alink (vzzzbx)
Assigned to: Jan Rittinger (tsheyar)
Summary: PF: child-steps + replace() fails to compile
Initial Comment:
The following query doesn't seem to get through step 18 of the pathfinder
compiler (it 'hangs')
What I tried:
- Leaving out the 'replace()' function, the query compiles fine
- Replacing one or more child steps into descendant steps in
"$rootnode//company/addressbook/name" makes it work fine, for example
"$rootnode//company//name"
(I used the pf that comes with Feb2009 release)
-----------------------------
declare function local:normCompanyName($name as xs:string) as xs:string {
normalize-space(replace(
upper-case(translate($name,",./()-"," "))
,"LIMITED","LTD"))
};
declare function local:companyList($rootnode as node()*) {
let $all := $rootnode//company/addressbook/name
let $uniqueNames := distinct-values(for $i in $all
return local:normCompanyName($i))
for $i in $uniqueNames
let $firstNode := $all[local:normCompanyName(.)=$i][1]
return $firstNode/../..
};
let $col := doc("%SOURCE%")
return local:companyList($col)
----------------------------------------------------------------------
>Comment By: Peter Boncz (boncz)
Date: 2009-04-07 13:50
Message:
forgot to say, memory consumption goes through the roof as well
Tasks: 257 total, 1 running, 254 sleeping, 2 stopped, 0 zombie
Cpu(s): 0.7%us, 1.3%sy, 0.0%ni, 96.4%id, 1.6%wa, 0.0%hi, 0.0%si,
0.0%st
Mem: 8199192k total, 8152836k used, 46356k free, 1244k buffers
Swap: 16579000k total, 5931108k used, 10647892k free, 24664k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18454 boncz 20 0 19248 1408 976 R 0.3 0.0 0:00.07 top
18397 boncz 20 0 10.0g 7.3g 284 T 0.0 93.6 0:53.21 pf
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2009-04-07 13:47
Message:
(gdb) bt
#0 better_or_equal (a=0x7fffcf717150, b=0x7fffcfc79010) at
/home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3247
#1 0x00000000004dd6c9 in prune_plans (planlist=0x7fffd0b11e20)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3186
#2 0x00000000004deec7 in plan_subexpression (n=0x7ffff7167c80)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3737
#3 0x00000000004dd906 in plan_subexpression (n=0x7ffff71682c0)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#4 0x00000000004dd906 in plan_subexpression (n=0x7ffff710d7c0)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#5 0x00000000004dd906 in plan_subexpression (n=0x7ffff710db70)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#6 0x00000000004dd906 in plan_subexpression (n=0x7ffff7168960)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#7 0x00000000004dd906 in plan_subexpression (n=0x7ffff7168fa0)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#8 0x00000000004dd906 in plan_subexpression (n=0x7ffff71694e0)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#9 0x00000000004dd906 in plan_subexpression (n=0x7ffff7131c90)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#10 0x00000000004dd906 in plan_subexpression (n=0x7ffff7131e30)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#11 0x00000000004dd906 in plan_subexpression (n=0x7ffff7169b30)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#12 0x00000000004dd906 in plan_subexpression (n=0x7ffff710fc50)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#13 0x00000000004dd906 in plan_subexpression (n=0x7ffff710ff10)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3305
#14 0x00000000004def85 in PFplan (root=0x7ffff710ff10) at
/home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3773
#15 0x000000000042ab46 in PFcompile (url=0x7fffffffe3c5 "t",
pfout=0x39b476c780, status=0x7fffffffdf00)
at /home/users/boncz/src/pathfinder/compiler/compile.c:683
#16 0x0000000000429ad5 in main (argc=2, argv=0x7fffffffe078) at
/home/users/boncz/src/pathfinder/compiler/main.c:1078
(gdb) l
3242 for (unsigned int j = 0; j < PFord_set_count
(a->orderings); j++) {
3243 /*
3244 * If the this order in a implies the current order in
b,
3245 * we are satisfied.
3246 */
3247 if (PFord_implies (
3248 PFord_set_at (a->orderings, j),
3249 PFord_set_at (b->orderings, i))) {
3250 satisfied = true;
3251 break;
(gdb) p PFord_set_count (a->orderings)
$4 = 107520
(gdb)
(gdb) finish
TAKES HALF A SECOND
Run till exit from #0 better_or_equal (a=0x7fffcf717150,
b=0x7fffcfc79010)
at /home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3247
0x00000000004dd6c9 in prune_plans (planlist=0x7fffd0b11e20) at
/home/users/boncz/src/pathfinder/compiler/algebra/planner.c:3186
3186 while (j < PFarray_last (in) &&
Value returned is $5 = false
(gdb) l
3164 for (unsigned int i = 0; i < PFarray_last (in); i++) {
(gdb)
3165 plan_t *cur = *(plan_t **) PFarray_at (in, i);
(gdb)
3168 bool found_better = false;
(gdb)
3171 for (unsigned int j = 0; j < PFarray_last (ret); j++)
(gdb)
3172 if (better_or_equal (*(plan_t **) PFarray_at (ret, j),
cur)) {
(gdb) p i
$8 = 4
(gdb) p *in
$9 = {base = 0x7fffcf30bc80, bound = 52, appi = 8, esize = 8, clear =
false}
(gdb) p *ret
$10 = {base = 0x7fffcf30bac0, bound = 51, appi = 4, esize = 8, clear =
false}
(gdb)
I think something needs to be done to cut off the search space...
----------------------------------------------------------------------
Comment By: Wouter Alink (vzzzbx)
Date: 2009-03-27 12:12
Message:
oops, for this bug I used by accident a pf-compiler from last months
'current'. I don't know whether the bug is still valid. The
Feb2009-pf-compiler does compile the query fine.
The pf-compiler I used for this query:
$ pf -h
Pathfinder XQuery Compiler ($Revision: 1.113 $, $Date: 2009/02/09 08:29:27
$)
(c) Database Systems Group, Eberhard Karls Universitaet Tuebingen
----------------------------------------------------------------------
Comment By: Wouter Alink (vzzzbx)
Date: 2009-03-27 12:05
Message:
oops, for this bug I used by accident a pf-compiler from last months
'current'. I don't know whether the bug is still valid. The
Feb2009-pf-compiler does compile the query fine.
The pf-compiler I used for this query:
$ pf -h
Pathfinder XQuery Compiler ($Revision: 1.113 $, $Date: 2009/02/09 08:29:27
$)
(c) Database Systems Group, Eberhard Karls Universitaet Tuebingen
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2716723&group_id=56967
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
