Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Date
Msg-id CAFj8pRDkxQGVCkwg30BjbgqQfBO67h95BBHBh=g4r0TGf0b2jg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs


2018-08-13 19:26 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Marko Tiikkaja <marko@joh.to> writes:
> On Mon, Aug 13, 2018 at 7:35 PM, Andres Freund <andres@anarazel.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


pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query
Next
From: Tom Lane
Date:
Subject: Re: BUG #15324: Non-deterministic behaviour from parallelised sub-query