FreeTDS Development Group

[brian AT bruns.com]

My understanding of parallelism is roughly this.  Rows are taken off
the input stream and "intraquery parallelism" is used to write them to
table partitions using two or more threads within the database engine
itself.  This should have no effect at the protocol level for FreeTDS.

This would be as if you issued a SQL query which used parallelism
internally.  The query is delivered to the server the same way, but
the engine itself breaks it apart and runs the component subqueries in
threads.

I'm gleaning much of this from Sybase, so if Microsoft turned right
where Sybase turned left it could be different, but I'm guessing they
are doing it the same basic way.  I'd like to hear if different.

Brian

On Fri, 30 Jul 2004 15:05:28 -0400, "Joseph Geiser" wrote:

> 
> > Perhaps you could provide a link to the page on Microsoft's web
site
> > that describes the feature you're talking about?  Because I don't
> know
> > of any parallelism provided by any bcp utility.  
> ...
> > As a comparison of the documentation shows, there are some feature
> > Microsoft's bcp.exe provides that freebcp does not, but I 
> > can't think of
> > anything called "parallelism".  
> 
> The "parallelism" I beleve that is being spoken of, is BCP's (and
> DTS's)
> ability to thread the copy process - using multiple threads to
populate
> multiple tables at the same time.
> 
> For example, if one uses DTS (which uses some bcp under the covers),
> and
> copies 4 tables from one database to another, it will usually spawn
two
> threads, copy the first two, and then reuse those threads to copy the
> other
> two.  If one finishes before the second, the freed up thread will
> usually
> (but not always) start on the third table while the second finishes -
> and
> after the second finishes, it goes on to the fourth.
> 
> (If I'm off base here - sorry about that - but it's the only thing I
> can
> think of in terms of bcp and parallel processing.)
> 
> Regards,
> Joe