From: | Georgios Kokolatos <gkokolatos(at)pm(dot)me> |
---|---|
To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Cc: | Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Subject: | Re: Duplicate Workers entries in some EXPLAIN plans |
Date: | 2020-01-16 14:07:36 |
Message-ID: | 157918365684.742.12107252182824730539.pgcf@coridan.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Sounds good, I'll try that format. Any idea how to test YAML? With the
> JSON format, I was able to rely on Postgres' own JSON-manipulating
> functions to strip or canonicalize fields that can vary across
> executions--I can't really do that with YAML.
Yes, this approach was clear in the patch and works great with Json. Also
you are correct, this can not be done with YAML. I spend a bit of time to
look around and I could not find any tests really on yaml format.
> Or should I run EXPLAIN
> with COSTS OFF, TIMING OFF, SUMMARY OFF and assume that for simple
> queries the BUFFERS output (and other fields I can't turn off like
> Sort Space Used) *is* going to be stable?
I have to admit with the current diff tool used in pg_regress, this is not possible.
I am pretty certain that it *is not* going to be stable. Not for long anyways.
I withdraw my suggestion for YAML and currently awaiting for TEXT format only.
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-01-16 14:17:36 | Re: PATCH: standby crashed when replay block which truncated in standby but failed to truncate in master node |
Previous Message | Emre Hasegeli | 2020-01-16 14:00:24 | Re: empty range |