First of all thanks for bringing this Feature to PostgreSQL. From a
regular-user perspective (not everyone is a Pro) it is very misleading
that ANALYZE doesn't do what it suggests it does. To run the query into
some kind of /dev/null type of destination is feasible and that is what
people end up doing after they have fallen into the "de-toasting" trap.
Having SERIALIZE is a great improvement for certain. When I said that
SERIALIZE should be the default, then this came mostly out of very
surprising subjective experiences in the past. Turning it on certainly
alters some existing benchmarks and timings. That is destructive in a
way and would destroy some existing work and measures. I lack the
overall understanding of the consequences, so please don't follow this
(emotional) advice.
So thanks again! and this will really help a lot of people. The people
actually bothering with EXPLAIN options are likely to explore the
documentation and now have a hint about this pitfall. The EXPLAIN part
of PostgreSQL "feels" a lot better now.
I appreciate all of your work on this issue, which came up without being
on some kind of plan and of course for the overall work on PostgreSQL.
/Stepan
On 4/10/24 15:57, Tom Lane wrote:
> Matthias van de Meent <boekewurm+postgres@gmail.com> writes:
>> Upthread at [0], Stepan mentioned that we should default to SERIALIZE
>> when ANALYZE is enabled. I suspect a patch in that direction would
>> primarily contain updates in the test plan outputs, but I've not yet
>> worked on that.
>> Does anyone else have a strong opinion for or against adding SERIALIZE
>> to the default set of explain features enabled with ANALYZE?
> I am 100% dead set against that, because it would silently render
> EXPLAIN outputs from different versions quite non-comparable.
>
> regards, tom lane