Re: improve EXPLAIN for wide tables

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

In response to

Responses

Browse pgsql-hackers by date

  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