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

2017-11-25 Thread Dmitry Shalashov
Ok, understood :-) Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-25 18:42 GMT+03:00 Tom Lane : > Michael Paquier writes: > > 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 Postg

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

2017-11-25 Thread Tom Lane
Michael Paquier writes: > 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 somethin

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

2017-11-25 Thread Dmitry Shalashov
> The author is also working on Postgres for 20 years, > so this gives some insurance. I know. Tom is a legend. But still I'd like to hear from him to be sure :) Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-25 15:13 GMT+03:00 Michael Paquier : > On Sat, Nov 25, 2017 at 8:54 PM, Dmitry S

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 use in production f

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: insert and query performance on big string table with pg_trgm

2017-11-25 Thread Gábor SZŰCS
Don't know if it would make PostgreSQL happier but how about adding a hash value column and creating the unique index on that one? May block some false duplicates but the unique index would be way smaller, speeding up inserts. 2017. nov. 25. 7:35 ezt írta ("Jeff Janes" ): > > > On Nov 21, 2017 00