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.



Read-Only Read-Only Topic
Go
Search
Notify
Tools
[SOLVED] run time
 Login/Join
 
Platinum Member
posted
We have learned that when we use a DEFINE to make a field and then use that field in a WHERE statement in the same TABLE FILE statement, the fex runs slower because it creates the new field for every record in the TABLE before actually going through the WHERE statements.

It therefore, would stand to reason that if you were to use a COMPUTE to define your new field in the TABLE FILE statement and then do a WHERE TOTAL statement on that field, it would not effect your runtime like the DEFINE would.

Is this correct? I've experimented with the CAR file, but it runs so fast anyway, that I can't really tell if there is any time savings.

This message has been edited. Last edited by: Mark1,


Windows version 768
 
Posts: 215 | Registered: March 16, 2006Report This Post
Master
posted Hide Post
A define is by definition done on row-level, BEFORE the actual query.

When you use it in a where is logical that the DBMS has to apply the define on row level before being able to check it against the WHERE.

And yes, a COMPUTE can accomplish the same a DEFINE.
But the COMPUTE is executed by the WF-engine. A Define is done by the DBMS-engine.
The last one being the quickest, usually.


But consider this:

I've a query to detect price-cuts.

define file x
  pricecut/A1 = if standard_price gt customer_price then 'Y' else 'N';
end

table file x
  sum units
  by day
where pricecut eq 'y';
end


With a COMPUTE:
I have 2.000.000 rows in the dbms, I'll get 2.000.000 back from the DBMS for WF to apply the computes and filters.


With the define I get 1 line for each day.
I'd rather have the DBMS filter all none price-cut lines BEFORE sending them to the WF-engine.

It really depends on the amount of data retrieved, the complexity of the defines, speed of the DBMS and WF systems.
Hard to predict which is the fastest.

G'luck.


_____________________
WF: 8.0.0.9 > going 8.2.0.5
 
Posts: 668 | Location: Veghel, The Netherlands | Registered: February 16, 2010Report This Post
Virtuoso
posted Hide Post
When doing development work against a relational data source, you should always have SQL traces turned on so you can see the SQL code generated by your WebFOCUS request. If you also set XRETRIEVAL=OFF you can see the generated SQL without extracting any data from the DB. This information will go a long way towards telling you the most efficient way to code your WebFOCUS request. Generally, the more work performed by the DBMS (record selection, aggregation, sorting, etc.) the better performing the query. Today, the WebFOCUS parser/translator can pass many DEFINEs and even some COMPUTEs, including related filtering, to the DBMS. But without viewing the generated SQL it is impossible to know for sure what is being passed to the DBMS for processing and what is not.

In some situations, the execution plan created by the DBMS for your query can degrade performance even when your query produces seemingly efficient SQL code. Sometimes it is necessary to see the exection plan to know exactly where the problem lies. Your DBA should be able to help you get execution plan information for a particular query.


WebFOCUS 7.7.05
 
Posts: 1213 | Location: Seattle, Washington - USA | Registered: October 22, 2007Report This Post
  Powered by Social Strata  

Read-Only Read-Only Topic


Copyright © 1996-2020 Information Builders