Re: Query became very slow after 9.6 -> 10 upgrade
Dmitry Shalashov <skaurus@gmail.com>
From: Dmitry Shalashov <skaurus@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael.paquier@gmail.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2017-11-25T18:59:40Z
Lists: pgsql-hackers, pgsql-performance
Ok, understood :-) Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-25 18:42 GMT+03:00 Tom Lane <tgl@sss.pgh.pa.us>: > Michael Paquier <michael.paquier@gmail.com> writes: > > On Sat, Nov 25, 2017 at 8:54 PM, Dmitry Shalashov <skaurus@gmail.com> > wrote: > >> Is it completely safe to use manually patched version in production? > > > Patching upstream PostgreSQL to fix a critical bug is something that > > can of course be done. And to reach a state where you think something > > is safe to use in production first be sure to test it thoroughly on a > > stage instance. The author is also working on Postgres for 20 years, > > so this gives some insurance. > > It's not like there's some magic dust that we sprinkle on the code at > release time ;-). If there's a problem with that patch, it's much more > likely that you'd discover it through field testing than that we would > notice it during development (we missed the original problem after all). > So you can do that field testing now, or after 10.2 comes out. The > former seems preferable, if you are comfortable with building a patched > copy at all. I don't know what your normal source of Postgres executables > is, but all the common packaging technologies make it pretty easy to > rebuild a package from source with patch(es) added. Modifying your > vendor's SRPM (or equivalent concept if you're not on Red Hat) is a > good skill to have. > > regards, tom lane >
Commits
-
Improve planner's handling of set-returning functions in grouping columns.
- df3a66e282b6 11.0 landed
- b9fc2d0b97c1 10.2 landed