Re: BUG #18091: Unexpected Result by enable_material
От | Francisco Olarte |
---|---|
Тема | Re: BUG #18091: Unexpected Result by enable_material |
Дата | |
Msg-id | CA+bJJbwtQRkgSAkK8Lztdy4eYLpEvdofx7KAJa-P+QxJOp6heA@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #18091: Unexpected Result by enable_material (PG Bug reporting form <noreply@postgresql.org>) |
Список | pgsql-bugs |
On Thu, 7 Sept 2023 at 09:10, PG Bug reporting form <noreply@postgresql.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.
В списке pgsql-bugs по дате отправления: