From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | bajinsheng(at)u(dot)nus(dot)edu, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18091: Unexpected Result by enable_material |
Date: | 2023-09-07 07:30:38 |
Message-ID: | CA+bJJbwtQRkgSAkK8Lztdy4eYLpEvdofx7KAJa-P+QxJOp6heA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, 7 Sept 2023 at 09:10, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> The same query returns different results when enable_material is changed:
I'm not too sure your query is guaranteed to return the same result
allways, let me see..
-- Zapping t4....
> CREATE TABLE t2(c1 DECIMAL, c2 serial);
> INSERT INTO t2(c2) VALUES(1), (2);
> INSERT INTO t2(c1) VALUES(0.1);
This seems to leave t2 as (null,1),(null,2),(0.1,1)
--
...
> SELECT DISTINCT ON (t2.c1) t2.c2 FROM t2, t4; -- {1}, {1}
> SELECT DISTINCT ON (t2.c1) t2.c2 FROM t2, t4; -- {1}, {2}
And this seems to ask for one row from
(null,1,{a,b,c})+(null,2,{a,b,c}), another from (0.1,1,{a,b,c})
So your result would be (1|2) + 1 ( in any order ), as the first set
can be scanned/selected in any order ( and the results returned in any
order )
Normally postgres would not bother on generating different outputs if
nothing is changed, but I think any response in {1,1},{1,2},{2,1} is
correct. Enable_material is probably just changing some access order
details.
You may be able to get better repeatable results using order by judiciously.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2023-09-07 07:35:16 | Re: BUG #18092: Unexpected Result by enable_seqscan |
Previous Message | PG Bug reporting form | 2023-09-07 05:52:59 | BUG #18092: Unexpected Result by enable_seqscan |