That worked!

Thanks!

The Length value on the output was coming out as 10, which really threw me. But Transpose corrected that. My computer is older with only 2 CPUs so my final query was:

CloseKernels[]; LaunchKernels[2]
AbsoluteTiming[
 Length[
  Transpose[
   list4ClassMStar = 
    ParallelMap[
     StarData[m1, #] &, {"Name", "HDNumber", "SpectralClass", 
      "BVColorIndex", "EffectiveTemperature", "Mass", "Luminosity", 
      "AbsoluteMagnitude", "ApparentMagnitude", "Constellation"}]]]]

{182.006, 4258}

Still 3.5 times slower than the same query using AstronomicalData.

What worries me is that StarData is a replacement for AstronomicalData. And ClassMStar was one of the small categories, at 4000 members. Many other star class categories hold 18-26,000 stars. So if a StarData group of 4000 stars takes 3 minutes, while a AstronomicalData group takes under 60 seconds, we are still looking at long access times for common star classes {A,B,F,G,K} etc. And the newer class data in StarData has even more stars in each class category. The amount of data being transferred is actually pretty small by todays standards, and the fact that older AstronomicalData format is 3 times faster, still points to StarData format as a performance issue. Could be as simple as StarData residing on newer data servers that queue throttle a request by resource usage, into slower priority work queues. Or StarData may be stored in a different database format, that does not perform as well as AstronomicalData database format. Only Wolfram would know. In either case, Wolfram should fix this issue, as it may also be shared across other curated data groups, not just StarData.