Focal Point Banner


As of December 1, 2020, Focal Point is retired and repurposed as a reference repository. We value the wealth of knowledge that's been shared here over the years. You'll continue to have access to this treasure trove of knowledge, for search purposes only.

Join the TIBCO Community
TIBCO Community is a collaborative space for users to share knowledge and support one another in making the best use of TIBCO products and services. There are several TIBCO WebFOCUS resources in the community.

  • From the Home page, select Predict: WebFOCUS to view articles, questions, and trending articles.
  • Select Products from the top navigation bar, scroll, and then select the TIBCO WebFOCUS product page to view product overview, articles, and discussions.
  • Request access to the private WebFOCUS User Group (login required) to network with fellow members.

Former myibi community members should have received an email on 8/3/22 to activate their user accounts to join the community. Check your Spam folder for the email. Please get in touch with us at community@tibco.com for further assistance. Reference the community FAQ to learn more about the community.


Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     How efficient is a DEFINE based on a constant?

Read-Only Read-Only Topic
Go
Search
Notify
Tools
How efficient is a DEFINE based on a constant?
 Login/Join
 
Anonymouse
Silver Member
posted
It's been a long time since I took the FOCUS internals class. Is FOCUS "smart" enough to evaluate only once a DEFINEd field that is based on a constant? What if that constant is an amper variable? What if the constant is another DEFINEd field? Some examples:

TODAY/MDYY = '&MDYY';
SUNDAY/MDYY = DATEMOV(TODAY, 'BOW') - 1;

I'll need to do some filtering using SUNDAY on millions of records.

...
WHERE OTHER_DATE GT SUNDAY
...

Is it OK to define this field, or is it more efficient to create an amper variable outside of the TABLE request and use the amper variable in the WHERE statement (WHERE OTHER_DATE GT '&SUNDAY')?
 
Posts: 34 | Location: Minneapolis, MN | Registered: June 10, 2003Report This Post
Francis Mariani
Expert
posted Hide Post
If you're accessing a SQL table, my guess would be that the DATEMOV function would not be translated to SQL, hence a very inefficient program.
 
Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005Report This Post
dwf
Platinum Member
posted Hide Post
In the internal matrix (or whatever they're calling it these days), FOCUS treats a defined field the same as a database field. It's just a column in the internal table. In other words, your field will exist in every row in the internal matrix. Even if it does evaluate it only once (and I don't think it does), you'll incur extra processing time due to extra I/O. An amper variable in your WHERE will be much more efficient.

The problem will be worse if you are accessing a relational database. If I am not mistaken (and I could be), using a defined field in a WHERE statement turns off the optimizer.
 
Posts: 135 | Location: Portland, OR | Registered: March 23, 2005Report This Post
Leah
Virtuoso
posted Hide Post
You're correct, define is on every record based on WITH also. Using define in WHERE will result in optimizer turn off if only selection is on the defined field. If you have other real fields it brings back as much as it can in the answer set before the defined selection. That is my understanding any way.

Not as efficient as on real fields, but sometimes the only way you can do what you want to do.
 
Posts: 1317 | Location: Council Bluffs, IA | Registered: May 24, 2004Report This Post
codermonkey
Platinum Member
posted Hide Post
Using a defined date field as part of your selection criteria for a relational database will fail optimization. Because part of the record selection fails, the RDBMS will also not be able to perform and sorting or aggregation. This can push a lot of the work back to FOCUS to handle and gets inefficient very quickly.

The good news is you can perform a lot of the same date functions used in DEFINEs within dialog manager commands. Because DM is evaluated before the SQL request is built, the where condition results in a test against a date constant -- which does translate. Here is some DM that should pull the same results as your defines:

-SET &BOWDT=DATECVT((DATEMOV((DATECVT(&YYMD,'I8YYMD','YYMD')),'BOW')),
- 'YYMD', 'I8YYMD');
-SET &SUNDAY=DATECVT((DATEADD((DATECVT(&BOWDT,'I8YYMD','YYMD')),'D',
- -1)),'YYMD', 'I8YYMD');
-TYPE &BOWDT
-TYPE &SUNDAY

Your where condition would now read
WHERE OTHER_DATE GT &SUNDAY
 
Posts: 118 | Location: DC | Registered: May 13, 2005Report This Post
j.gross
Virtuoso
posted Hide Post
Capture the Sunday date in an amper var...
[qb]
-SET &XTODAY=&YYMD;
-SET &XDATE1=DATECVT(&XTODAY,'I8YYMD','YYMD');
-SET &XDATE2=DATEMOV(&XDATE1,'BOW');
-SET &XSUNDAY=DATECVT(&XDATE2,'YYMD','I8YYMD');
-SET &SUNDAY=EDIT(&XSUNDAY,'9999-99-99');
-? &X
[/qb]
[qb]
CURRENTLY DEFINED & VARIABLES STARTING WITH 'X':
&XDATE1 = 38202
&XDATE2 = 38199
&XSUNDAY = 20050801
&XTODAY = 20050804
> >
[/qb]
...and use the &var in your test:
[qb] WHERE OTHER_DATE GE '&SUNDAY';[/qb]
TABLE will see a comparison to a date constant:
[qb] WHERE OTHER_DATE GE '2005-08-01';[/qb]
and, assuming OTHER_DATE is a real field, will pass the condition through to the rdms.
 
Posts: 1925 | Location: NYC | In FOCUS since 1983 | Registered: January 11, 2005Report This Post
Anonymouse
Silver Member
posted Hide Post
Thanks all. I hadn't thought of the relational optimization issue, but that's definitely a larger factor here than my original question.

FYI, sorting does not necessarily get turned off (at least it didn't in my simple tests on DB2), but aggregation does of course.
 
Posts: 34 | Location: Minneapolis, MN | Registered: June 10, 2003Report This Post
Anonymouse
Silver Member
posted Hide Post
One more thing. Be careful when using DATEMOV and the BOW option. BOW is always a Monday, and if the input date is a Saturday or Sunday, it is the next Monday! Therefore, if "today" is a Saturday, BOW puts you into next week! There is another topic on this subject that was begun July 1 2005. I don't like the solution at the end (DOWK and offsets seems cleaner to me) but I guess it works.
 
Posts: 34 | Location: Minneapolis, MN | Registered: June 10, 2003Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic

Focal Point    Focal Point Forums  Hop To Forum Categories  WebFOCUS/FOCUS Forum on Focal Point     How efficient is a DEFINE based on a constant?

Copyright © 1996-2020 Information Builders