From: | Marko Tiikkaja <marko(at)joh(dot)to> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Fletcher <andy(at)prestigedigital(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
Date: | 2018-08-14 10:22:02 |
Message-ID: | CAL9smLAnfPJCDUUG4ckX2iznj53V7VSMsYefzZieN93YxTNOcw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Aug 14, 2018 at 7:10 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> Yeah, one idea could be that we detect this in
> max_parallel_hazard_walker during the very first pass it performs on
> query-tree. Basically, in the SubLink node check, we can detect
> whether the subselect has Limit/Offset clause and if so, then we can
> treat it as parallel_unsafe. I have tried that way and it prohibits
> the parallel plan for the reported queries. However, I think more
> analysis and verification is required to see if it can happen in any
> other related cases.
>
This seems broken as well:
create table qwr(a int not null, b int not null, c text not null);
insert into qwr select i, i, (select prosrc from pg_proc where
oid=11734) from generate_series(1, 128000) i;
set parallel_setup_cost to 0;
analyze qwr;
select count(*) from qwr where (a, b) in (select a, row_number() over()
from qwr);
.m
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-08-14 11:09:19 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
Previous Message | Amit Kapila | 2018-08-14 07:36:07 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |