Andres Freund <and...@2ndquadrant.com> writes:
>> Just for some clarity, that also happens with expressions like:
>> WHERE
>> ROW(ev_class, rulename, ev_action) >= ROW('pg_rewrite'::regclass, '_RETURN',
>> NULL)
>> ORDER BY ROW(ev_class, rulename, ev_action);
> Previously we wouldn't detoast ev_action here, but now we do.
No, we don't; not in that WHERE expression, because it's a RowCompareExpr
which does not involve forming any composite datums. We'd only detoast if
the row comparison actually gets to that column --- which is the same
behavior as before.
The extra detoast you're seeing in this example is caused by the ROW()
in the ORDER BY. Which, as I said, is just bad SQL coding.
> I agree that this needs to get backpatched at some point. But people
> also get very upset if queries gets slower by a magnitude or two after a
> minor version upgrade. And this does have the potential to do that, no?
They don't get nearly as upset as they do if the database loses their
data. Yes, in an ideal world, we could fix this and not suffer any
performance loss anywhere. But no such option is on the table, and
waiting is not going to make one appear. What waiting *will* do is
afford more opportunities for this bug to eat people's data.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
