On 2014-04-27 18:44:16 -0400, Tom Lane wrote:
> 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.
> ...
> 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.
Good point.
> > 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.
We make tradeoffs between performance and safety *all the time*. A new
performance regression that has the potential of affecting a fair number
of installations very well can be worse than a decade old correctness
bug. A bug that only will hit in some specific usage scenarios and will
only affect individual datums.
And you *have* come up with an alternative approach. It might very well
be inferior, but that certainly doesn't make this approach one without
alternatives.
Anyway, I've now voiced my doubts about immediate backpatching. Any
other opinions?
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
