From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jwieck(at)debis(dot)com (Jan Wieck) |
Cc: | hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] equal: don't know whether nodes of type 600 are equal |
Date: | 1999-02-07 17:44:38 |
Message-ID: | 5054.918409478@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
jwieck(at)debis(dot)com (Jan Wieck) writes:
> Tom Lane wrote:
>> I think the real problem is that the EXCEPT/INTERSECT code is dependent
>> on rewrite work that is not being done in the EXPLAIN path, and that
>> we need to fix that underlying problem rather than patching the symptom.
> I added the call to QueryRewrite() in ExplainQuery() some
> time ago. So the comment in ExplainOneQuery() isn't right
> (and I should have removed that).
ttest=> select 1 union select 2;
?column?
--------
1
2
(2 rows)
ttest=> explain select 1 union select 2;
ERROR: copyObject: don't know how to copy 604
ttest=>
This error is coming from inside the planner (specifically union_planner).
Obviously there's *something* different about the context in which the
planner is invoked for EXPLAIN.
It looks to me like the problem is that some rewrite code got placed in
pg_parse_and_plan() in postgres.c --- there is some UNION-handling stuff
going on *after* the call to QueryRewrite(), and evidently that stuff
is not duplicated in the EXPLAIN case. Probably the right fix is to
move all that logic inside QueryRewrite() --- but I don't want to touch
it without confirmation from someone who knows the parser/planner
better.
Some quick checks with gdb show union_planner() being invoked only once
when the query is executed for real, but recursively when using EXPLAIN
... and it's the recursive call that is throwing the error:
#0 elog (lev=-1, fmt=0x2ef20 "copyObject: don't know how to copy %d")
at elog.c:79
#1 0xae994 in copyObject (from=0x400a5028) at copyfuncs.c:1870
#2 0xae93c in copyObject (from=0x400a5250) at copyfuncs.c:1859
#3 0xc7888 in new_unsorted_tlist (targetlist=0xffffffff) at tlist.c:314
#4 0xc03a0 in union_planner (parse=0x400a5028) at planner.c:110
#5 0xc40d4 in plan_union_queries (parse=0x400a53b8) at prepunion.c:146
#6 0xc03f0 in union_planner (parse=0x400a53b8) at planner.c:131
#7 0xc0320 in planner (parse=0x400a53b8) at planner.c:80
#8 0x8dc64 in ExplainOneQuery (query=0x400a53b8, verbose=0 '\000', dest=604)
at explain.c:92
#9 0x8dc24 in ExplainQuery (query=0x400a5670, verbose=0 '\000', dest=Remote)
at explain.c:76
#10 0x1012e8 in ProcessUtility (parsetree=0x400a52d8, dest=Remote)
at utility.c:781
#11 0xfeba0 in pg_exec_query_dest (
query_string=0x7b0342b0 "explain select a from tt union select a from tt;",
dest=Remote, aclOverride=92 '\\') at postgres.c:819
#12 0xfe9f8 in pg_exec_query (
query_string=0xffffffff <Address 0xffffffff out of bounds>)
at postgres.c:711
#13 0xffbfc in PostgresMain (argc=316064, argv=0x51, real_argc=5,
real_argv=0x40002b10) at postgres.c:1664
I wonder whether union_planner() is even really needed anymore given the
rewrite stuff ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-02-07 18:03:21 | Re: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Previous Message | Jan Wieck | 1999-02-07 17:30:43 | v6.4.3 ? |