Oh dang! It does not appear that makeparallel() will help you get a parallel plan here...

First, here's a little background on the function:

Some time ago Paul White wrote an amazing article about how to force a parallel plan using an undocumented trace flag (8649). Here's a quick demo:

Using this sample data:

USE tempdb

GO

IF OBJECT_ID('tempdb.dbo.t') IS NOT NULL DROP TABLE dbo.t;

GO

CREATE TABLE dbo.t

(METRO_STATUS varchar(20) not null, URBAN int);

INSERT t (METRO_STATUS)

VALUES ('Urban'),('xxx'),('xxx'),('Urban');

You could use the traceflag like this:

SELECT t.*

FROM t

OPTION (RECOMPILE, QUERYTRACEON 8649);

Blam! Parallel query plan. The problem is that this is an undocumented and unsupported trace flag and therefore unacceptable in a production environment. (which is why I don't recommend it except for testing in non-prod environments)

Then Adam Mechanic came up with the aforementioned makeparallel() function that, until now, usually behaves exactly the same. To use it in a SELECT statement you would use CROSS APPLY like so...

SELECT t.*

FROM t

CROSS APPLY dbo.make_parallel();

Anyhow, I never tried makeparallel() in an update statement... It's easy with the traceflag but a little tricky with makeparallel... After some tinkering I came up with:

WITH tu AS

(

SELECT

METRO_STATUS,

URBAN

FROM t

CROSS APPLY make_parallel()

)

UPDATE tu

SET URBAN = CASE METRO_STATUS WHEN 'Urban' THEN 1 ELSE 0 END

This is getting me a parallel zone in the query plan but the the update is still serial. I am going to play with this a little more but I am beginning to think that makeparallel is the right solution here. I am going to tinker around with this a little and get back to you.

If anything I would read Paul's article and Adams article - they are super-informative.

Mr. Magoo... If you are out there perhaps you could chime in:w00t: you know much more about this than I do...