Hacker Newsnew | comments | show | ask | jobs | submit login

I agree with what you have to say, but I don't see how you can determine that this query:

SELECT * FROM table WHERE id > 5 LIMIT 10;

is actually of the same form as this query:

SELECT * FROM table WHERE id > 10 LIMIT 5;

without actually parsing the two. I mean you will incur a parsing overhead either way. What I think MemSQL is trying to optimize out is the actual execution of the query. I mean rather than interpreting and running it with checks performed in every iteration, they are compiling the code. I don't know how much of a difference this would make without actually seeing the numbers.




That's why prepared statements are preferable because those two statements have to be parsed as unique queries. They are actually the same query with different parameters.

As far as I know that's the same on just about all databases.

-----


At least some databases I've used have parsed out constants in the client library code and submitted prepared statements to the server, passing those constants in. That meant that the server got better use out of its query cache; on the server side, those are the same query.

Not sure which ones if any do this today, the optimisation might no longer be relevant - I spotted DBs doing this 10 years ago when CGIs that didn't bother with prepared statements were rife.

-----


@nikita I see: http://developers.memsql.com/docs/1b/faq.html#does-this-mean...

Do you mean you determine placeholders without actually parsing the SQL?

@jakejake The docs. seem to suggest that the benefits of prepared statements are won without using prepared statements in MemSQL.

-----


Not every parsing is equal. MySQL and other databases produce a tree as they parse a query. If you just want to match parameters you can avoid memory allocations and just replace parameters with ^ or @ signed in place in the query string.

http://developers.memsql.com/docs/1b/faq.html gives some more details.

-----




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: