Skip to Content.
Sympa Menu

freetds - Re: large queries and TDS 7.0 revisited

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: large queries and TDS 7.0 revisited
  • Date: Sun, 22 Oct 2000 21:45:24 -0400 (EDT)



Query times are a combination of size of result set (columns and rows) and
the usefulness of indexes and the query optimizers ability to generate a
decent query plan. You may want to run it with showplan and noexec to see
if your query plan is any good. The size of the query text in the process
should be negligible and more importantly has nothing to do with the
client (ours or microsofts). Of course there could be a bug, but I find
it hard to envision anything the small query/large query code differences
could be doing to cause it.

On to the meat of your post. There should only be one reference to '512'
left in write.c (And I just checked in the fix for that...) If you are
seeing more, then the snapshot is not picking up the right stuff.

Why not send me the text of the query offlist and I'll run it through
under TDS 4.2 with the latest code to see what's up.

Brian

On Sun, 22 Oct 2000, Michael Kimsal wrote:

> Gotta jump in here and say 'help'.
>
> Following this thread, I'm guessing that the latest snapshot (10/22)
> should now be able to handle large queries in SQL7. Whoah wait - nope,
> this is TDS7. OK sorry.
>
> Brian, I'm still using TDS4.2 on SQL7, but queries over 512 bytes die.
> Using an older snapshot from September sometime, they work, but, for
> example, a 622 byte query is taking 150 milliseconds. *dozens* of
> smaller queries before it are taking less than half that time combined. :(
>
> Anyone got any ideas?
>
> I changed the 'write.c' references to 512 bytes up to 4096, but that
> just breaks everything. I know there's something I'm missing, and I know
> this
> has been beat to death, but I'd really like to have long queries in SQL7,
> with TDS4.2, and have them work quickly.
>
> Thanks all.
>
>
>
>
> Brian Bruns wrote:
>
> > Hi Brandon,
> >
> > Thanks for taking on of my long overdue TODO items :-)
> >
> > It looks great. I've just committed the patch to the CVS tree so it should
> > be there in a few.
> >
> > Brian
> >
> > On Wed, 18 Oct 2000, Brandon M. Reynolds wrote:
> >
> > > Thanks Brian. That does solve my problem with large queries, but
> > > only with ctlib. I created a patch for making the dbbuf dynamic
> > > in the DBPROCESS structure. Would you pretty please apply this
> > > patch so that long queries work with dblib too?
> > >
> > > diff -urN freetds/include/sybdb.h freetds.10182000/include/sybdb.h
> > > --- freetds/include/sybdb.h Sat Oct 7 15:32:32 2000
> > > +++ freetds.10182000/include/sybdb.h Wed Oct 18 09:01:02 2000
> > > @@ -150,7 +150,8 @@
> > > int noautofree;
> > > int more_results; /* boolean. Are we expecting
> > > results? */
> > > BYTE *user_data; /* see dbsetuserdata() and
> > > dbgetuserdata()
> > > */
> > > - unsigned char dbbuf[8192]; /* XXX should be dynamic
> > > */
> > > + unsigned char *dbbuf; /* is dynamic! */
> > > + int dbbufsz;
> > > int empty_res_hack;
> > > TDS_INT text_size;
> > > TDS_INT text_sent;
> > > diff -urN freetds/src/dblib/dblib.c freetds.10182000/src/dblib/dblib.c
> > > --- freetds/src/dblib/dblib.c Sun Oct 8 22:19:09 2000
> > > +++ freetds.10182000/src/dblib/dblib.c Wed Oct 18 09:17:22 2000
> > > @@ -449,8 +449,9 @@
> > > }
> > >
> > > dbproc->tds_socket = (void *) tds_connect(login->tds_login);
> > > - dbproc->dbbuf[0]='\0'; /* initialize query buffer */
> > > -
> > > + dbproc->dbbuf = NULL;
> > > + dbproc->dbbufsz = 0;
> > > +
> > > if(dbproc->tds_socket) {
> > > tds_set_parent( dbproc->tds_socket, dbproc);
> > > tds_add_connection(g_tds_context, dbproc->tds_socket);
> > > @@ -465,9 +466,26 @@
> > > }
> > > RETCODE dbcmd(DBPROCESS *dbproc, char *cmdstring)
> > > {
> > > - /* here is one of those large static buffers that should be
> > > malloced
> > > - ** but in the interest of time i kludged :) */
> > > - strcat(dbproc->dbbuf,cmdstring);
> > > + if(dbproc->dbbufsz == 0) {
> > > + if((dbproc->dbbuf =
> > > + (unsigned char *)malloc(strlen(cmdstring)+1)) ==
> > > NULL) {
> > > + return FAIL;
> > > + }
> > > + strcpy(dbproc->dbbuf,cmdstring);
> > > + dbproc->dbbufsz = strlen(cmdstring) + 1;
> > > + } else {
> > > + int newsz;
> > > + void *p;
> > > +
> > > + newsz = strlen(cmdstring) + dbproc->dbbufsz;
> > > + if((p=realloc(dbproc->dbbuf,newsz)) == NULL) {
> > > + return FAIL;
> > > + }
> > > + dbproc->dbbuf = (unsigned char *)p;
> > > + strcat(dbproc->dbbuf,cmdstring);
> > > + dbproc->dbbufsz = newsz;
> > > + }
> > > +
> > > return SUCCEED;
> > > }
> > > RETCODE dbsqlexec(DBPROCESS *dbproc)
> > > @@ -534,6 +552,7 @@
> > > }
> > > free(dbproc->bcp_columns);
> > > }
> > > + dbfreebuf(dbproc);
> > >
> > > free(dbproc);
> > > tds_del_connection(g_tds_context, dbproc->tds_socket);
> > > @@ -1618,7 +1637,11 @@
> > >
> > > void dbfreebuf(DBPROCESS *dbproc)
> > > {
> > > - dbproc->dbbuf[0] = '\0';
> > > + if(dbproc->dbbuf) {
> > > + free(dbproc->dbbuf);
> > > + dbproc->dbbuf = NULL;
> > > + }
> > > + dbproc->dbbufsz = 0;
> > > } /* dbfreebuf() */
> > >
> > > RETCODE dbclropt(DBPROCESS *dbproc,int option, char *param)
> > > @@ -1895,7 +1918,7 @@
> > > }
> > > if (! dbproc->noautofree)
> > > {
> > > - dbproc->dbbuf[0]='\0';
> > > + dbfreebuf(dbproc);
> > > }
> > > result = SUCCEED;
> > > }
> > >
> >
>
> --
> ==========================
> Michael Kimsal
> http://www.tapinternet.com
> 734-480-9961
>
>
>
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>





Archive powered by MHonArc 2.6.24.

Top of Page