Re: Parallel Sort

On Mon, May 13, 2013 at 04:39:01PM +0200, Andres Freund wrote:
> On 2013-05-13 10:28:59 -0400, Noah Misch wrote:
> > Each worker needs to make SnapshotNow visibility decisions coherent with the
> > master. For sorting, this allows us to look up comparison functions, even
> > when the current transaction created or modified those functions.
>
> I don't really see how you can achieve that given how SnapshotNow
> works. There's nothing protecting you against one backend seeing changes
> made by another transaction while another doesn't see them. SnapshotNow
> doesn't even guarantee consistency within a single backend during a
> single scan...
> If you are meaning the above to just apply to changes made by the local
> "master" backend, sure I can see that.

Yes; it only makes the workers consistent with the master to the extent that
the master is consistent with itself. However, your comment makes me see that
this may not be enough. For an object not protected by locks, if parallel
execution probes the syscache N times where the current code probes it only
once, we'll introduce new anomalies. I don't think this affects sorting in
particular, because we already make little effort to behave sanely when a
comparison function is redefined mid-sort. It seems likely that this will
need a better answer sooner or later as we move into the parallelism space.

Thanks,
nm

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com