Re: improve EXPLAIN for wide tables
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2024-12-17T20:58:36Z
Lists: pgsql-hackers
I wrote: > Sami Imseih <samimseih@gmail.com> writes: >> I am attaching a patch that deals with the RTE_JOIN case. > I'll take a look. Thanks for the test demonstrating that > this makes a visible performance difference. Pushed with some simplification: we don't need a new flag, because none of the callers of set_simple_column_names need it to do anything with join RTEs. This is better anyway because set_relation_column_names' comment explicitly says it is not for join RTEs, and now we don't use it on them ever. I poked at the question of whether it's worth skipping unique-ification for relation RTEs, and I came to the same conclusion as you: it doesn't seem to be. The related code is down in the noise according to "perf" once we skip join RTEs. I think the reason the join RTEs are so expensive for this is that the upper ones get very wide in join nests like the example query. regards, tom lane
Commits
-
Skip useless calculation of join RTE column names during EXPLAIN.
- 7a80e381d16c 18.0 landed
-
Use a hash table to de-duplicate column names in ruleutils.c.
- 52c707483ce4 18.0 cited