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,

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.

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.