Subject: RE: Issues with multi-queries - msg#00014

Previous Message by Date: click to view message preview

Re: Issues with multi-queries

Paul Martin wrote: I read through the comments in query.h as well and that restated it. Actually, that form isn't for human consumption directly. The reference manual is generated from these specially-formatted comments, so it's easier to read it there. http://tangentsoft.net/mysql++/doc/html/refman/ next time I'll RTFM a little more closely. That's always good, but also, follow the examples. If the examples do something, don't just remove it if you're not certain why it's there. Put another way: I've actively tried to cut the code in the examples down as far as I can to make them as simple as possible. What's left is all essential, in one way or another. No fluff. With that in mind, if I am calling query.execute() instead of store() how do I consume the rest of the results? You don't, so don't do that. More FM to R: http://tangentsoft.net/mysql++/doc/html/userman/tutorial.html#id2839723 -- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx

Next Message by Date: click to view message preview

Re: Issues with multi-queries

Ian Daysh wrote: what is considered a "sufficiently large result set" for the Query::store object? It's simply a question of whether the result set fits in available RAM. If you run the system out of RAM or VM, switching to a use() query is one of several ways out of the pitfall. It's pretty low on my list of preferred alternatives, though: - Put a little more thought into your WHERE clauses: let MySQL do as much filtering as is practical. Saves memory, saves bandwidth, can even save CPU time. - If you can't put the filter in the query, maybe you can do it with Query::store_if(). This is built atop a use() query, so it only stores the records that the functor returns true for. - Second-guess all "SELECT *" queries: do you really need _all_ the columns in the table at this time? When calculating this, beware that MySQL++ deals exclusively in textual forms of data from the database. This results in a kind of storage bloat when dealing with "binary" data types, such as numeric and BLOB types. For instance, a MEDIUMINT takes two bytes on disk, but it's as much as 5 characters in text form, plus the overheads required by the C API and MySQL++. Thus, if you know each row takes 1 KB on disk and you pull a million rows, you're going to need a whole lot more than 1 GB of memory to hold it. You gots to axe yourself, though: do you really need a million rows all at once? That's what motivates the list above. Fix the data volume problem at the source before you tackle the matter of storing the entire result set in RAM or dealing with it one record at a time. -- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx

Previous Message by Thread: click to view message preview

Re: Issues with multi-queries

Paul Martin wrote: I read through the comments in query.h as well and that restated it. Actually, that form isn't for human consumption directly. The reference manual is generated from these specially-formatted comments, so it's easier to read it there. http://tangentsoft.net/mysql++/doc/html/refman/ next time I'll RTFM a little more closely. That's always good, but also, follow the examples. If the examples do something, don't just remove it if you're not certain why it's there. Put another way: I've actively tried to cut the code in the examples down as far as I can to make them as simple as possible. What's left is all essential, in one way or another. No fluff. With that in mind, if I am calling query.execute() instead of store() how do I consume the rest of the results? You don't, so don't do that. More FM to R: http://tangentsoft.net/mysql++/doc/html/userman/tutorial.html#id2839723 -- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx

Next Message by Thread: click to view message preview

Re: Issues with multi-queries

Ian Daysh wrote: what is considered a "sufficiently large result set" for the Query::store object? It's simply a question of whether the result set fits in available RAM. If you run the system out of RAM or VM, switching to a use() query is one of several ways out of the pitfall. It's pretty low on my list of preferred alternatives, though: - Put a little more thought into your WHERE clauses: let MySQL do as much filtering as is practical. Saves memory, saves bandwidth, can even save CPU time. - If you can't put the filter in the query, maybe you can do it with Query::store_if(). This is built atop a use() query, so it only stores the records that the functor returns true for. - Second-guess all "SELECT *" queries: do you really need _all_ the columns in the table at this time? When calculating this, beware that MySQL++ deals exclusively in textual forms of data from the database. This results in a kind of storage bloat when dealing with "binary" data types, such as numeric and BLOB types. For instance, a MEDIUMINT takes two bytes on disk, but it's as much as 5 characters in text form, plus the overheads required by the C API and MySQL++. Thus, if you know each row takes 1 KB on disk and you pull a million rows, you're going to need a whole lot more than 1 GB of memory to hold it. You gots to axe yourself, though: do you really need a million rows all at once? That's what motivates the list above. Fix the data volume problem at the source before you tackle the matter of storing the entire result set in RAM or dealing with it one record at a time. -- MySQL++ Mailing List For list archives: http://lists.mysql.com/plusplus To unsubscribe: http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx