2015-01-29 11:57 GMT-02:00 Tom Worster <f...@thefsb.org>: > Hi Oleksandr, > > I'm going to stop bitching about Maria now. My needs are in fact met by > the current dyncol functions: > > - It's not so hard to write methods that generate CREATE_COLUMN() > expressions from a general data structure. > > - COLUMN_JSON() is just fine for all my reading purposes. I see no need > for a naked COLUMN_GET() in a SELECT. >
take care, when you return more data than you really need, you use more network, memory, cpu, cache, buffers... something like SELECT * FROM table, when you only need SELECT column_a FROM table with big system or small hardware you may have problems > > - Generating COLUMN_GET() expressions for use in queries ends up being a > regex replace with some packaging. > take care with the size of final query... for example SELECT COLUMN_GET(),COLUMN_GET(),COLUMN_GET()..... 256 times FROM table if your network is a problem, maybe is better SELECT column FROM table, and execute the column_get at client side, this reduce network, and memory used at client and server side with the SQL string (query) > - As I said in the email to Frederico this morning, indexes are not > unimportant but a lot of apps can live without and many will be fine. > When I wrote my original email, that list of seven concerns were factors > in my vague worry that dyncols are going to remain ignored and unloved. > i like and use them =] but i don't love dynamic column without index, today i execute workarounds to solve this > That original email is adequately answered and I have the information I > need. > nice =] > > Tom
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp
