From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: improve EXPLAIN for wide tables |
Date: | 2024-12-17 04:47:05 |
Message-ID: | CAA5RZ0tAzs1en1qfc+TKBs4W=Dq3P6mi07WSRi04wrZ-tkpTiw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> But if the column names are ambiguous within the same RTE, how does
> table-qualification fix that? And it's within-the-same-RTE that
> we're concerned with here
> It only takes one case to mean we have to deal with it ;-). But I'm
> fairly sure that there are many other cases, since the parser doesn't
> restrict the output names of a sub-SELECT to be unique.
good point. I see the error in my original line of thinking now.
In fact, it's this simple to prove that we still need to unique-ify
something like this subquery is valid:
select * from (select 1 a, 2 a) as s
> I had a thought about this: I don't think EXPLAIN is ever required
> to print the names of join alias variables (since the planner flattens
> all join alias variables to some kind of expression over their
> underlying columns). So we could skip assigning column names to
> join RTEs at all, if we know that it's EXPLAIN rather than view/rule
> decompilation. That might let us skip all the mess around
> unique-ifying JOIN USING column names, too.
That makes sense and a comment inside deparse_context_for_plan_tree
describes this from what I can tell.
/*
* Set up column name aliases. We will get rather bogus results for join
* RTEs, but that doesn't matter because plan trees don't contain any join
* alias Vars.
*/
set_simple_column_names(dpns);
I suspect that we can also skip RTE_RELATION, since columns must
be unique, but I am not sure it's worth the extra effort. At least my test
does not show any real benefit.
I am attaching a patch that deals with the RTE_JOIN case.
# HEAD
postgres=# SELECT FROM v1 WHERE false;
--
(0 rows)
Time: 494.572 ms
postgres=# EXPLAIN SELECT FROM v1 WHERE false;
QUERY PLAN
------------------------------------------
Result (cost=0.00..0.00 rows=0 width=0)
One-Time Filter: false
(2 rows)
Time: 1236.127 ms (00:01.236)
# with the patch applied
postgres=# SELECT FROM v1 WHERE false;
--
(0 rows)
Time: 503.049 ms
postgres=# EXPLAIN SELECT FROM v1 WHERE false;
QUERY PLAN
------------------------------------------
Result (cost=0.00..0.00 rows=0 width=0)
One-Time Filter: false
(2 rows)
Time: 525.812 ms
Regards,
Sami
Attachment | Content-Type | Size |
---|---|---|
0001-v1-skip-join-RTE-in-deparse_context_for_plan_tree.patch | application/octet-stream | 2.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-12-17 05:00:10 | Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4) |
Previous Message | Kirill Reshke | 2024-12-17 04:31:46 | Re: on_error table, saving error info to a table |