From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jud Gardner <jgardner(at)comprehend(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15232: Query execution changes based on using 'explain analyze' or not |
Date: | 2018-06-08 01:24:07 |
Message-ID: | CAEepm=3rvRBxD_g8RngT6nAtUuTdGskL0xdDK3WXroebLDRwgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Fri, Jun 8, 2018 at 5:06 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jud Gardner <jgardner(at)comprehend(dot)com> writes:
>> When submitted through psql I don't see the issue.
>> I also don't see it when submitting via jdbc (42.2.2) directly.
>
>> I'm seeing this via jdbc through dbVisualizer, haven't seen this kind of
>> behavior before.
>
> Interesting. It could be that dbVisualizer is setting some parameter
> or transaction mode that prevents parallelism. SERIALIZABLE mode
> does so, for example, because the serializable-transaction logic
> hasn't been taught about parallelism yet.
It plans a parallel query, but it's sending an Execute message with
max_rows = 1000. That causes PortalRun() to be called with run_once =
false, which causes execute_once to be false here:
/*
* If the plan might potentially be executed multiple times,
we must force
* it to run without parallelism, because we might exit early.
*/
if (!execute_once)
use_parallel_mode = false;
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-06-08 03:09:38 | Re: BUG #15225: [XX000] ERROR: invalid DSA memory alloc request size 1073741824 / Where: parallel worker |
Previous Message | PG Bug reporting form | 2018-06-07 21:35:53 | BUG #15233: Error in estimation leads to very bad parralel plan in simple 2 table join. |