"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Dave Page <dpage@postgresql.org> writes:
>> Looking to fix this, a comment in src/backend/commands/explain.c
>> indicates that this is intentional:
>
> Quite.
>
>> Anyone know why?
>
> As already noted, it'd usually be clutter in lines that are too long
> already. Also, conditionally adding a schema name isn't very good
> because it makes life even more complicated for programs that are
> parsing EXPLAIN output (yes, there are some).
Arguably this is a bug if it's causing pg_admin difficulties in parsing the
output. Even for a user in an environment where, for example, he has several
identical schemas and may be accidentally getting a different table than he's
expecting the current output is ambiguous.
Attached is a small patch which adds this conditionally on a guc that pg_admin
or other GUI tools could set, leaving it unchanged for users.
But it doesn't really seem like all that much clutter to add it to the scans
all the time:
QUERY PLAN
--------------------------------------------------------------------------------------------------------------
Nested Loop (cost=3.77..1337.74 rows=62 width=8)
-> Hash Join (cost=3.77..92.30 rows=123 width=8)
Hash Cond: (p.oid = (a.aggfnoid)::oid)
-> Seq Scan on pg_catalog.pg_proc p (cost=0.00..78.49 rows=2349 width=4)
-> Hash (cost=2.23..2.23 rows=123 width=8)
-> Seq Scan on pg_catalog.pg_aggregate a (cost=0.00..2.23 rows=123 width=8)
-> Index Scan using pg_operator_oid_index on pg_catalog.pg_operator o (cost=0.00..10.11 rows=1 width=4)
Index Cond: (o.oid = a.aggsortop)
Filter: (NOT (subplan))
SubPlan
-> Index Scan using pg_amop_opr_fam_index on pg_catalog.pg_amop (cost=1.05..9.33 rows=1 width=0)
Index Cond: (amopopr = $1)
Filter: ((amopmethod = $0) AND (amoplefttype = $2) AND (amoprighttype = $3))
InitPlan
-> Seq Scan on pg_catalog.pg_am (cost=0.00..1.05 rows=1 width=4)
Filter: (amname = 'btree'::"name")
(16 rows)
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com