Re: Query became very slow after 9.6 -> 10 upgrade

От: Tom Lane
Тема: Re: Query became very slow after 9.6 -> 10 upgrade
Дата: ,
Msg-id: 5549.1511456440@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov)
Ответы: Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov)
Список: pgsql-performance

Скрыть дерево обсуждения

Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
 RE: Query became very slow after 9.6 -> 10 upgrade  ("Alex Ignatov", )
  Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
   RE: Query became very slow after 9.6 -> 10 upgrade  ("Alex Ignatov", )
    Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
     Re: Query became very slow after 9.6 -> 10 upgrade  (Tomas Vondra, )
 Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )
  Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
   Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )
    Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
     Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )
      Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
       Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )
        Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
         Re: Query became very slow after 9.6 -> 10 upgrade  (Michael Paquier, )
          Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
          Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )
           Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
    Re: Query became very slow after 9.6 -> 10 upgrade  (Dmitry Shalashov, )
   Re: Query became very slow after 9.6 -> 10 upgrade  (Tom Lane, )

Dmitry Shalashov <> writes:
> We tried to apply the patch on 10.1 source, but something is wrong it seems:
> patch -p1 < ../1.patch
> (Stripping trailing CRs from patch; use --binary to disable.)
> patching file src/backend/optimizer/plan/analyzejoins.c
> (Stripping trailing CRs from patch; use --binary to disable.)
> patching file src/backend/utils/adt/selfuncs.c
> Hunk #1 succeeded at 3270 (offset -91 lines).
> Hunk #2 succeeded at 3304 (offset -91 lines).
> Hunk #3 succeeded at 3313 (offset -91 lines).
> Hunk #4 succeeded at 3393 (offset -91 lines).
> patch unexpectedly ends in middle of line
> Hunk #5 succeeded at 3570 with fuzz 1 (offset -91 lines).

The line number offsets are expected when applying to v10, but it looks
like you failed to transfer the attachment cleanly ... there were
certainly not CRs in it when I mailed it.  The output on v10
should just look like

patching file src/backend/optimizer/plan/analyzejoins.c
patching file src/backend/utils/adt/selfuncs.c
Hunk #1 succeeded at 3270 (offset -91 lines).
Hunk #2 succeeded at 3304 (offset -91 lines).
Hunk #3 succeeded at 3313 (offset -91 lines).
Hunk #4 succeeded at 3393 (offset -91 lines).
Hunk #5 succeeded at 3570 (offset -91 lines).
        regards, tom lane



В списке pgsql-performance по дате сообщения:

От: Mariel Cherkassky
Дата:
Сообщение: pgpool + repmgr - who should be responsible for failover
От: Daulat Ram
Дата:
Сообщение: Issue with postgres login