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
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
> 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
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
> 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
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 when can I expect 1
> 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 releas
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 --bin
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/
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 (select distinct
unnest(f
Turns out we had not 9.6 but 9.5.
And query plan from 9.5 is:
Sort (cost=319008.18..319008.19 rows=1 width=556) (actual
time=0.028..0.028 rows=0 loops=1)
Sort Key: (sum(st.shows)) DESC
Sort Method: quicksort Memory: 25kB
CTE a
-> Index Scan using adroom_active_idx on adroom (co
Dmitry Shalashov writes:
> BUT if I'll add to 3rd query one additional condition, which is basically
> 2nd query, it will ran same 12 minutes:
> SELECT adroom_id, domain_id, shows, clicks FROM adroom_stat WHERE day
> between date_trunc('day', current_timestamp - interval '1 week') and
> date_trunc
IMHO the problems here are due to poor cardinality estimates.
For example in the first query, the problem is here:
-> Nested Loop (cost=0.42..2.46 rows=1 width=59)
(actual time=2.431..91.330 rows=3173 loops=1)
-> CTE Scan on b (cost=0.00..0.02 rows=1 width=40)
nal: http://www.postgrespro.com
> The Russian Postgres Company
>
>
>
> *From:* Dmitry Shalashov [mailto:skau...@gmail.com]
> *Sent:* Wednesday, November 22, 2017 5:29 PM
> *To:* Alex Ignatov
> *Cc:* pgsql-performa...@postgresql.org
> *Subject:* Re: Query became very s
From: Dmitry Shalashov [mailto:skau...@gmail.com]
Sent: Wednesday, November 22, 2017 5:29 PM
To: Alex Ignatov
Cc: pgsql-performa...@postgresql.org
Subject: Re: Query became very slow after 9.6 -> 10 upgrade
Sure, here it goes:
nam
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
>
>
>
>
Sent: Wednesday, November 22, 2017 5:14 PM
To: pgsql-performa...@postgresql.org
Subject: Query became very slow after 9.6 -> 10 upgrade
Hi!
I've seen few letters like this on mailing list and for some reason thought
that probably it won't happen to us, but here I am lol.
It'
Hi!
I've seen few letters like this on mailing list and for some reason thought
that probably it won't happen to us, but here I am lol.
It's "nestloop hits again" situation.
I'll try to provide plan from 9.6 later, but right now I have only plan
from 10.1.
Query: https://pastebin.com/9b953tT7
I
18 matches
Mail list logo
