[FX.php List] PHP restriction on data transfer?

[Malcolm Fitzgerald]

On 23/03/2015 2:28 am, Bob Patin wrote:
> and that they should pull related records rather than pulling a 
> portal? I don’t ever pull directly from portals, which may be why I’ve 
> never seen this issue.
Portals are not the problem. They present the same issue that any table 
does - a portal represents a record set. The more important issue is 
that each record set also represents a query and possibly a sort. Data 
size on the network is less and less of a problem, so the extra number 
of records obtained by portals is not the problem. The processing of a 
separate query for each record in a found set is the real performance hit.

Call a portal P
Call the number of portals on a layout p.
Call the number of portals rows displayed by a portal x. If the scroll 
bar is displayed the number of portal rows is limited by memory, so x < ∞.
Call the number of records in the found set n.

When searching on any layout you will perform 1 + ( p * n )  queries and 
the found set will return n + ( n * (P_1 *x_1 + P_2 *x_2 ... P_p *x_p ) 
) records

You can see, that the size of n is just as important in this equation as 
the size of p. For each record you will have to perform 1 + p queries. 
Which is exactly the same amount of queries that you would have to do to 
obtain the data set if you do not use portals.

What's more, in the real world, the number represented by n is more 
likely to be large than the number represented by p. (You are more 
likely to have more records in a table than portals on a layout). If n 
doesn't get larger than one (1) you won't see performance problems with 
portals. So, control the size of n and let p look after itself.

Malcolm




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20150323/2f506f3e/attachment.html