← Back to team overview

maria-discuss team mailing list archive

Re: The future of Dynamic Columns


2015-01-29 11:57 GMT-02:00 Tom Worster <fsb@xxxxxxxxxx>:

> 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
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

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

Follow ups