From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: explain (verbose off, normalized) vs query planid |
Date: | 2018-05-15 20:16:55 |
Message-ID: | CA+TgmoZ=1ae9AHXhryoSGvkN9Wg9zCuhxzbVLtzazO0dKG1KDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, May 15, 2018 at 3:45 PM, legrand legrand
<legrand_legrand(at)hotmail(dot)com> wrote:
> Would there be some functional or performances reasons to prefer jumbling to
> hashing normalized plan text?
Using the text could produce different query IDs for the same plan if
any information is displayed in the text format which can vary for
reasons other than a plan change. I don't know if there are any, but
what about, for example, the effect of GUCs on how timestamps are
displayed? Or, much worse, what if a timer value creeps into the
output somehow? Certainly, renaming a table is going to change the
output. Even using a different table alias will change the output.
Using the text could produce the same query ID for different plans if
there's any relevant detail of the plan that's not shown in the text.
Basically, I would be nervous about the idea of an EXPLAIN output
that's required to reflect all and only the plan details that should
be jumbled. The "normalized" option to EXPLAIN which you mentioned
upthread doesn't exist today...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-05-15 20:57:01 | Re: index scan over composite type |
Previous Message | Tom Lane | 2018-05-15 20:10:58 | Re: Should total_pages be calculated after partition pruning and constraint exclusion? |