| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Marko Tiikkaja <marko(at)joh(dot)to> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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 15:44:10 |
| Message-ID: | 390.1534261450@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Marko Tiikkaja <marko(at)joh(dot)to> writes:
> Marking the function parallel safe doesn't seem wrong to me. The
> non-parallel-safe part is that the input gets fed to it in different order
> in different workers. And I don't really think that to be the function's
> fault.
So that basically opens the question of whether *any* window function
calculation can safely be pushed down to parallel workers.
Somewhat like the LIMIT/OFFSET case, it seems to me that we could only
expect to do this safely if the row ordering induced by the WINDOW clause
can be proven to be fully deterministic. The planner has no such smarts
at the moment AFAIR. In principle you could do it if there were
partitioning/ordering by a primary key, but I'm not excited about the
prospects of that being true often enough in practice to justify making
the check.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Bug reporting form | 2018-08-14 18:26:16 | BUG #15325: RHEL 6.10 exists, download.postgresql.org doesn't support it |
| Previous Message | Christopher Browne | 2018-08-14 13:46:11 | Re: Possible Spam(100.5):No receiving of password |