[thelist] CF - MAXROWS

rudy limeback r937 at interlog.com
Sat Jul 22 17:32:20 CDT 2000

>for example, let's suppose you have a query that returns results from some
>form of category table.  the total recordcount is less than, oh say, 50.
>how much advantage are you going to get when this sort of query is already
>1-2ms (or 0ms on an enterprise level database server

i guess it would go from fast to blindingly fast    ;o)

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

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

so i say, always use blockfactor regardless

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

>on the other hand, let's suppose you had a query that returned, oh say,
>records.  now that would be the one you'd wanna put that blockfactor of
>50 on and then put in startrow and maxrows attributes on your cfoutput to
>set up your page to only show 50 at a time.


not to be too picky, jeff, but you said "the database server still returns
all the records found and it's the cf server that actually cuts the records
available down to the maxrows value"

i think this needs clarification

when you submit a query to the database, it "gets" all the records -- but
only into its own buffer space

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

mmmmmm, maxrows   ;o)

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

for example, on the evolt site, i don't think there's a maxrows on the
query that gets center names, you know, the list that goes "Backend, Code,
Commentary & Society, Jobs..." down the right side

the page doesn't have "more..." logic for centers, it prints them all -- as
it should, because having centers that you have to hit a "more" link to see
would score low on the usability-meter

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

fifty category records is next to nothing in terms of buffer space

of course, if you go beyond fifty categories, and are listing them down the
side, you would probably want to re-think the design of the page, where the
centers are listed, maybe return only the top ten in descending order by
number of articles, and *then* use maxrows with a "more..." link

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



More information about the thelist mailing list