Re: Proposal: add a debug message about using geqo

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: KAWAMOTO Masaya <kawamoto(at)sraoss(dot)co(dot)jp>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: add a debug message about using geqo
Date: 2022-07-22 20:19:54
Message-ID: CAAWbhmgfDKNiSk01G5P4hxbi4jcyBriczaEE_gYaRTziqps6Tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 1, 2022 at 11:09 PM KAWAMOTO Masaya <kawamoto(at)sraoss(dot)co(dot)jp> wrote:
> That sounds a nice idea. But I don't think that postgres shows in the
> EXPLAIN output why the plan is selected. Would it be appropriate to
> show that GEQO is used in EXPLAIN output?

I'm reminded of Greenplum's "Optimizer" line in its EXPLAIN output
[1], so from that perspective I think it's intuitive.

> As a test, I created a patch that add information about GEQO to
> EXPLAIN output by the GEQO option. The output example is as follows.
> What do you think about the location and content of information about GEQO?

I am a little surprised to see GeqoDetails being printed for a plan
that didn't use GEQO, but again that's probably because I'm used to
GPDB's Optimizer output. And I don't have a lot of personal experience
using alternative optimizers.

One way to think about it might be, if we had ten alternatives, would
we want a line for each showing why it wasn't selected, or just one
line showing the optimizer that was selected? The latter is more
compact but doesn't help you debug why something else wasn't chosen, I
suppose...

--Jacob

[1] https://docs.vmware.com/en/VMware-Tanzu-Greenplum/6/greenplum-database/GUID-ref_guide-sql_commands-EXPLAIN.html#examples-4

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-07-22 20:37:35 predefined role(s) for VACUUM and ANALYZE
Previous Message Alvaro Herrera 2022-07-22 20:19:45 Re: make -C libpq check fails obscurely if tap tests are disabled