My premise was that SSELECT FILE BY @ID BY FIELDNAME is not the same as SSELECT FILE BY FIELDNAME.
The second one is technically SSELECT FILE BY FIELDNAME BY @ID My 1 cent Mark Johnson ----- Original Message ----- From: "Jerry Banker" <[EMAIL PROTECTED]> To: <u2-users@listserver.u2ug.org> Sent: Friday, August 10, 2007 10:32 AM Subject: RE: [U2] [UV] Speeding up a big BY.EXP select > I'm not exactly sure how the programming is done on this but from the > outside it is all relative to how you look at it. Let's take the > statement: > SSELECT CUSTOMERS BY NAME BY CITY > In one way it can be seen as: > Sort by name with each name sort by city with each city sort by key. > In another way of looking at it: > Sort by key go through the list pulling out, but retaining the key > order, sorting the cities then, retaining that order, sort by name. > Either way if you throw a BY @ID in there the SSELECT becomes redundant > and the SSELECT is done for no reason. > Jerry > > -----Original Message----- > From: MAJ Programming [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 09, 2007 6:24 PM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] [UV] Speeding up a big BY.EXP select > > Jerry: Are you sure. Please make sure that what you are saying is > correct. > The SSELECT statement has traditionally sorted on the @ID last for the > last > 30 years. It would be news to me to learn that it sorts BY @ID > automatically > first because of the double S in SSELECT. > > Thus > SSELECT FILE BY CITY > should be different than > SSELECT FILE BY @ID BY CITY > > as the first would gather all the records BY CITY then within each CITY, > they would be sorted by @ID (the default). > > Using @ID anywhere but the last sort field (or implied) would not make > sense > as they are guaranteed to be unique and not need a tie breaker. > > Please check again. > Thanks > Mark Johnson > ----- Original Message ----- > From: "Jerry Banker" <[EMAIL PROTECTED]> > To: <u2-users@listserver.u2ug.org> > Sent: Thursday, August 09, 2007 9:39 AM > Subject: RE: [U2] [UV] Speeding up a big BY.EXP select > > > > The way I see it the first one will take longer than the second, > > although it would have to be a large file you are selecting on. The > > reason would be that the first one sorts the ID's, redundantly, twice > > before it gets to the BY.EXP whereas the second one sorts by the ID > only > > once. > > > > -----Original Message----- > > From: Boydell, Stuart [mailto:[EMAIL PROTECTED] > > Sent: Thursday, August 09, 2007 2:27 AM > > To: u2-users@listserver.u2ug.org > > Subject: [U2] [UV] Speeding up a big BY.EXP select > > > > I have a large file with an MV set I need to do an exploding sort > > against (about 2 million records, about 20 MVs per record). I'm not > > actually after any particular sort order but it's taking hours. > > I'm wondering if there is any efficiency advantage by telling it to > use > > a primary sort on the ID or just to sort on the MV attribute? > > My (probably flawed) reasoning is that if the primary sort is on the > id > > then the sort process wouldn't have to build up one big explode - as > it > > would have a primary sort by record, it then only needs to explode > each > > record at a time. > > > > Eg. > > SSELECT BIGFILE BY @ID BY.EXP MV.ATTRIBUTE > > Or > > SSELECT BIGFILE BY.EXP MV.ATTRIBUTE > > > > Anyone know the answer to that one? > > > > Stuart Boydell > > > > > > > > ********************************************************************** > > This email message and any files transmitted with it are confidential > > and intended solely for the use of addressed recipient(s). If you have > > received this communication in error, please reply to this e-mail to > > notify the sender of its incorrect delivery and then delete it and > your > > reply. It is your responsibility to check this email and any > > attachments for viruses and defects before opening or sending them on. > > Spotless collects information about you to provide and market our > > services. For information about use, disclosure and access, see our > > privacy policy at http://www.spotless.com.au > > Please consider our environment before printing this email. > > ********************************************************************** > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > > ------- > > u2-users mailing list > > u2-users@listserver.u2ug.org > > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
