[thelist] CF - MAXROWS

[Jeff]

rudy,

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: From: rudy limeback <r937 at interlog.com>
:
: i guess it would go from fast to blindingly fast    ;o)
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

yes, but can you even see the speed different of one or two milliseconds on
a 100-150 ms page?

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: do that for enough queries and you have an app that
: flies rather than one that chugs along
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

true, but then you're template caching is affected.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: anyway, fifty category records is next to nothing in
: terms of buffer space
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

and neither is 1-2 ms.  *grin*

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: so i say, always use blockfactor regardless
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

which is why i think that they should be used wisely (after all, if the
default of 1 was such a performance no-no why is that the default?).

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: (i love these arguments where we are both on the
: same side <grin>)
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

yup.  got your frisbee ready?

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: it doesn't "return" all of them, in the sense of shipping
: them over to the cf server, unless the cf server keeps
: asking for enough blocks to hit end-of-file (as it were)
:
: the cf server says "gimme a block of records... okay,
: now gimme another block... and another..." until either
: the database says "there ain't no more" or the cf server
: *stops asking* because it's reached its maxrows limit
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

actually it was explained to me to be the other way by an allaire
instructor.  the database server returns all the records to the cf server
and it's up to the cf server to determine if there is a maxrows set on the
query or not and if so how many of the records to report (if more then the
maxrows setting).  that's why it's no real advantage (other than to limit
the number of records returned) to use maxrows on the cfquery tag.

i could be wrong with my understanding of this though.  even if i am, using
maxrows on the cfquery tag doesn't limit the work of the database as it
still gets all the records for that query before talking to the cf server
and handing them over.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: mmmmmm, maxrows   ;o)
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

pass the steak sauce please.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: where would you put a high blockfactor and not
: bother with maxrows?  wherever you want or expect
: to handle the entire results set on the page
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

i'm not sure that i'd ever really want to set the maxrows in the cfquery
tag.  i'd be more inclined to use startrow and maxrows and break up the
results over several "pages".  if i can expect that the results would be too
many to show on one page when they realisticly should, then i'd have to
rethink my design (either database or layout).

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: so the designer of this query would omit maxrows
: and set blockfactor to what, like around 50?
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

for the time necessary to include the blockfactor attribute and actually
thinking about what value you should give it i'm not sure you'd ever recoup
that time in the cumulative milliseconds you'd gain from it.  one of the
places we'd really gain though is in the query that returns the list of
articles for the front page and previous 10/next 10 links.

:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: isn't it neat how web page design and database
: query design are inextricably intertwined
:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

true, true

thanks,

.jeff

name://jeff.howden
game://web.development
http://www.evolt.org/
mailto:jeff at members.evolt.org