Re: Latest advice on SSD?

2018-04-10 Thread Dmitry Shalashov
could be easily faster than 1GB/s and up to 3GB/s+. I'm curious to know where are you drawing these conclusions from? 1. https://blog.seagate.com/enterprises/mach2-and-hamr-breakthrough-ocp/ Dmitry Shalashov, relap.io & surfingbird.ru 2018-04-10 22:00 GMT+03:00 Aaron : > RDBMS s

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

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

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

2017-11-25 Thread Dmitry Shalashov
kinda hope for some security problem :) Is it completely safe to use manually patched version in production? Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-24 19:39 GMT+03:00 Tom Lane : > Dmitry Shalashov writes: > > It looks that patch helps us. Tom, thank you! > > I&#

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

2017-11-24 Thread Dmitry Shalashov
schedule on releasing fixes like this? Can I expect that it will be in 10.2 and when can I expect 10.2, approximately of course? Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-23 20:00 GMT+03:00 Tom Lane : > Dmitry Shalashov writes: > > We tried to apply the patch on 10.1 source, b

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

2017-11-23 Thread Dmitry Shalashov
z 1 (offset -91 lines). Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-23 2:07 GMT+03:00 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: > > r

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

2017-11-22 Thread Dmitry Shalashov
-> CTE Scan on b (cost=0.00..2.00 rows=100 width=40) (actual time=0.007..0.007 rows=0 loops=1) Planning time: 6.641 ms Execution time: 0.203 ms Also I prepared test case for Tom and sent it to him. Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-22 18:19 GMT+03:00 Tom Lane

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

2017-11-22 Thread Dmitry Shalashov
xt, (CURRENT_TIMESTAMP - '7 days'::interval))) AND (day <= date_trunc('day'::text, CURRENT_TIMESTAMP)) AND (domain_id = d.id)) Dmitry Shalashov, relap.io & surfingbird.ru 2017-11-22 17:44 GMT+03:00 Alex Ignatov : > Here is my select right after initdb: > &

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

2017-11-22 Thread Dmitry Shalashov
m > The Russian Postgres Company > > > > > > *From:* Dmitry Shalashov [mailto:skau...@gmail.com] > *Sent:* Wednesday, November 22, 2017 5:14 PM > *To:* pgsql-performa...@postgresql.org > *Subject:* Query became very slow after 9.6 -> 10 upgrade > > > >

Query became very slow after 9.6 -> 10 upgrade

2017-11-22 Thread Dmitry Shalashov
cost=0.58..25524.33 rows=491 width=16) (actual time=104.847..240.846 rows=474 loops=3043) Index Cond: ((day >= date_trunc('day'::text, (CURRENT_TIMESTAMP - '7 days'::interval))) AND (day <= date_trunc('day'::text, CURRENT_TIMESTAMP)) AND (domain_id = (unnest(adroom.domain_ids Planning time: 1.580 ms Execution time: 71.740 ms Dmitry Shalashov, relap.io & surfingbird.ru