Re: Parallel safety of CURRENT_* family - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallel safety of CURRENT_* family
Date
Msg-id 18600.1480632100@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel safety of CURRENT_* family  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Broken SSL tests in master
Next
From: Robert Haas
Date:
Subject: Re: Mail thread references in commits