From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Marko Tiikkaja <marko(at)joh(dot)to>, Andres Freund <andres(at)anarazel(dot)de>, andy(at)prestigedigital(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
Date: | 2018-08-13 17:47:37 |
Message-ID: | CAFj8pRDkxQGVCkwg30BjbgqQfBO67h95BBHBh=g4r0TGf0b2jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
2018-08-13 19:26 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Marko Tiikkaja <marko(at)joh(dot)to> writes:
> > On Mon, Aug 13, 2018 at 7:35 PM, Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >> Well, the subselect with thelimit going to return different results from
> >> run to run. Unless you add an ORDER BY there's no guaranteed order in
> >> which tuples are returned. So I don't think it's surprising that you're
> >> getting results that differ between runs.
>
> > While this is true, that's missing the point.
>
> Yeah, I agree. I think probably what's happening is that the sub-select
> is getting pushed down to the parallel workers and they are not all
> computing the same set of sub-select results, leading to inconsistent
> answers at the top level.
>
> Likely, we need to treat the presence of a LIMIT/OFFSET in a sub-select
> as making it parallel-unsafe, for exactly the reason that that makes
> its results non-deterministic.
>
Isn't it default behave of LIMIT/OFFSET without ORDER BY clause?
If we don't need to solve order of rows, then parallel unsafe is not
necessary.
Regards
Pavel
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-13 18:04:47 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |
Previous Message | Tom Lane | 2018-08-13 17:26:45 | Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query |