From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | 梁海安(Killua Leung) <LIANGHAIAN001(at)pingan(dot)com(dot)cn> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Different plan between 9.6 and 9.4 when using "Group by" |
Date: | 2017-05-29 18:21:01 |
Message-ID: | CAMkU=1waxrmkJNxwPbC2cEjBFxYSFfdEEL1qSwDe1yC9DnAdJQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, May 27, 2017 at 1:40 AM, 梁海安(Killua Leung) <
LIANGHAIAN001(at)pingan(dot)com(dot)cn> wrote:
> Hi team:
>
> The following SQL is very slow in 9.6.1 for the plan has a “sort”
> node.
>
The difference is only a factor of 2. I wouldn't call it "very" slow.
Your explain plans are unreadable, please try posting them as
un-line-wrapped text files, or using something like
https://explain.depesz.com/, to share them in a readable way. (Also,
VERBOSE probably isn't doing us much
good here, and makes it much less readable).
Writing your CTEs as inline subqueries might help the planner make some
better choices here. Also, the estimate for CTE n is so bad, I'm guessing
that their is a high functional dependency on:
a.mapping_code = b.mapping_code AND a.channel=b.channel
While the planner is assuming they are independent. You might be able to
get better estimates there by doing something like:
a.mapping_code+0 = b.mapping_code+0 AND a.channel=b.channel
(or using ||'' rather than +0 if the types are textual rather than
numerical). But I doubt it would be enough of a difference to change the
plan, but it is an easy thing to try.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin.Hughes@uk.fujitsu.com | 2017-05-30 07:34:26 | Re: Client Server performance & UDS |
Previous Message | phb07 | 2017-05-27 15:42:54 | Re: Monitoring tool for Postgres Database |