Monty Taylor schrieb:
Ulf Wendel wrote:
Brian tried to kick off some brainstorming on PS in his blog [1]. Both
he and Lukas Smith [2], as of shortly a [Co-]Release Manager of the PHP
5.3 series, have blogged about PS before I found time to raise my voice
on PDO and PS [3]. Its been a rather vivid blog discussion.
Things I remember from the discussion:
- current PS implementation of the server does not scale well
And never will.
- todays developers are lazy and maybe less skilled:
they rely on garbage collections and keep handles open
for ages - the server
- the server does not do much more than cache the parse tree:
parsing can make 25% of the run-time of a short query
Well, the parsing problem is actually a whole other conversation I'm
trying to have... (in short, I want to push parsing to the client
library and have the ability to send the parse-tree over the wire)
There is more behind than just parsing.
The concept of Prepared Statements came up at a time when I was still in
the Kindergarten or maybe not even planned to be ever born. From what I
know, PS are designed for classical host applications. The setup
consists of a single central database server and limited number of a few
hundred workstations. The workstations run the same program all day.
Probably even with less dynamic SQL. Its been the times of embedded SQL.
A perfect world for caching as much as you can on the server:
- parse-trees
- execution plans
- DB internal file system handles
- ... - whatever resource you can "cache" or "reserve"
Clients change only once per day, many recurring queries with just a
little bit different parameters etc.
Typical web applications should be characterized by a far higher number
of clients. And the more clients, the more challenging it is to scale on
a central element. I get that.
But can we move all of the theoretical benefits of server-side PS
towards the client? I see that a client can parse SQL and do parameter
substituition. But what about:
- execution plans
- DB internal file system handles
- ... - whatever resource you can "cache" or "reserve"
- binary protocol can mean significantly less conversions
- binary protocol can mean less traffic
What is the Drizzle roadmap on Prepared Statements given that PHP, a
major player in the web market, will not play nicely with Drizzle
without a vision implemented by Drizzle and MySQL Connector team folks?
If you want to scale in a massive web scale out environment, Server-Side
prepared statements are a terrible idea. Full stop. Same thing with
So, the Drizzle idea is on client-side PS. But how do they work? What
about parser updates? Will Drizzle make the SQL parser a plugin that
clients can use as well?
Whether the server-side has PS or not or they are any good or not, I
can't believe PHP can't provide a good emulation layer for their users
That's not at the hearth of my question. It may be possible to develop a
solid client-side PS emulation for PHP. But it will take time and
resources. As long as its not available you will hear the PHP folks, the
self-declared target audience for Drizzle, bail at you.
The question is on the how to do it, assuming that we really think that
preparing (= caching) statements makes sense at all.
Ulf
--
Ulf Wendel, MySQL
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering Muenchen: HRB161028
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
