From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 5bih4k+4jfl6m39j23k(at)guerrillamail(dot)com, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel safety of CURRENT_* family |
Date: | 2016-12-01 22:41:40 |
Message-ID: | 18600.1480632100@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Yeah, I didn't have any doubt that it was real. Still don't know
> why my test case isn't doing what I expected, though.
Doh: the planner knows that transaction_timestamp() is stable, so
it concludes that the DISTINCT condition is vacuous. There is a
"Unique" node in the plan, but it has zero columns to compare, so
it thinks the tuple are all equivalent and emits only the first.
I had noticed that there was no "Sort" node, but failed to realize
that that implied the "Unique" node was degenerate.
Maybe this is over-optimization, but I think we'd be very sad if
the planner didn't do it; getting rid of useless sort columns is
critical in a lot of situations.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2016-12-01 22:44:46 | Re: Mail thread references in commits |
Previous Message | Michael Paquier | 2016-12-01 21:53:48 | Re: Broken SSL tests in master |