Prev: dblink regression failure in HEAD
Next: [HACKERS] Last call for patches for the July CommitFest
From: Yeb Havinga on 13 Jul 2010 04:50 Tom Lane wrote: > The reason I'm on about this at the moment is that I think I see how to > get ruleutils to print PARAM_EXEC Params as the referenced expression > rather than $N ... Wouldn't this obfuscate the plan more than printing subplan arguments at the call site? regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 13 Jul 2010 10:10 Yeb Havinga <yebhavinga(a)gmail.com> writes: > Tom Lane wrote: >> The reason I'm on about this at the moment is that I think I see how to >> get ruleutils to print PARAM_EXEC Params as the referenced expression >> rather than $N ... > Wouldn't this obfuscate the plan more than printing subplan arguments at > the call site? It would if subplans could have more than one call site, but they can't. I do intend to force qualification of Vars that are printed as a result of param expansion; for example consider a standard nestloop-with- inner-indexscan plan: NestLoop Seq Scan on a Index Scan on b Index Cond: x = a.y If y weren't qualified to show that it's not a variable of b, this could be confusing. But as long as we do that, it pretty much matches our historical behavior. Note that CVS HEAD is printing this case as NestLoop Seq Scan on a Index Scan on b Index Cond: x = $0 which is definitely not very helpful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Yeb Havinga on 13 Jul 2010 11:21 Tom Lane wrote: > Yeb Havinga <yebhavinga(a)gmail.com> writes: > >> Tom Lane wrote: >> >>> The reason I'm on about this at the moment is that I think I see how to >>> get ruleutils to print PARAM_EXEC Params as the referenced expression >>> rather than $N ... >>> >> Wouldn't this obfuscate the plan more than printing subplan arguments at >> the call site? >> > > It would if subplans could have more than one call site, but they can't. > > I do intend to force qualification of Vars that are printed as a result > of param expansion; > Will the new referenced expression printing also be used when printing subplans? If yes, I do not have to submit the latest version of a patch I made for subplan argument printing (discussed earlier in this thread http://archives.postgresql.org/pgsql-hackers/2010-02/msg01602.php) regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 13 Jul 2010 14:14 Yeb Havinga <yebhavinga(a)gmail.com> writes: > Will the new referenced expression printing also be used when printing > subplans? > If yes, I do not have to submit the latest version of a patch I made for > subplan argument printing (discussed earlier in this thread > http://archives.postgresql.org/pgsql-hackers/2010-02/msg01602.php) Oh, I had forgotten that patch was still in progress. I think it's unnecessary given what I'm fooling with. The attached patch needs some more testing, but what I get with it is for example regression=# explain (verbose) select (select oid from pg_class a where regression(# a.oid = b.relfilenode) from pg_class b; QUERY PLAN -------------------------------------------------------------------------------------------------------- Seq Scan on pg_catalog.pg_class b (cost=0.00..5556.81 rows=669 width=4) Output: (SubPlan 1) SubPlan 1 -> Index Scan using pg_class_oid_index on pg_catalog.pg_class a (cost=0.00..8.27 rows=1 width=4) Output: a.oid Index Cond: (a.oid = b.relfilenode) (6 rows) (this is the first example in the above-referenced thread). regards, tom lane
|
Pages: 1 Prev: dblink regression failure in HEAD Next: [HACKERS] Last call for patches for the July CommitFest |