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

2017-11-25 Thread Michael Paquier
On Sat, Nov 25, 2017 at 8:54 PM, Dmitry Shalashov 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

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

2017-11-25 Thread Dmitry Shalashov
> Excellent, please follow up if you learn anything new. Sure. But my testing is over and something new might come out only incidentally now. Testing hasn't reveal anything interesting. > That will probably be in > early February, per our release policy: ok, thanks. That makes me kinda hope for

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

2017-11-24 Thread Tom Lane
Dmitry Shalashov writes: > It looks that patch helps us. Tom, thank you! > I'm still testing it though, just in case. Excellent, please follow up if you learn anything new. > What are PostgreSQL schedule on releasing fixes like this? Can I expect > that it will be in 10.2 and

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

2017-11-24 Thread Dmitry Shalashov
> The line number offsets are expected when applying to v10, but it looks > like you failed to transfer the attachment cleanly ... Yes, it was some mistake on our side. It looks that patch helps us. Tom, thank you! I'm still testing it though, just in case. What are PostgreSQL schedule on

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

2017-11-23 Thread 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

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

2017-11-23 Thread Dmitry Shalashov
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

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

2017-11-22 Thread Tom Lane
Dmitry Shalashov writes: > Turns out we had not 9.6 but 9.5. I'd managed to reproduce the weird planner behavior locally in the regression database: regression=# create table foo (f1 int[], f2 int); CREATE TABLE regression=# explain select * from tenk1 where unique2 in

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

2017-11-22 Thread Dmitry Shalashov
grespro.com > The Russian Postgres Company > > > > *From:* Dmitry Shalashov [mailto:skau...@gmail.com] > *Sent:* Wednesday, November 22, 2017 5:29 PM > *To:* Alex Ignatov <a.igna...@postgrespro.ru> > *Cc:* pgsql-performa...@postgresql.org > *Subject:* Re: Query bec

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

2017-11-22 Thread Alex Ignatov
Dmitry Shalashov [mailto:skau...@gmail.com] Sent: Wednesday, November 22, 2017 5:29 PM To: Alex Ignatov <a.igna...@postgrespro.ru> Cc: pgsql-performa...@postgresql.org Subject: Re: Query became very slow after 9.6 -> 10 upgrade Sure, here it goes: name