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

  1. Improve planner's handling of set-returning functions in grouping columns.