NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Don't use that on a high volume site (Score:1)
At least not against a good database. (eg Oracle, PostgreSQL, etc - but MySQL would be fine.)
The problem is that there is a trade-off between time spend preparing a query and query performance. It would not be inappropriate to think of preparing a query as a "compile and optimize this SQL" step. MySQL spends very little energy preparing, and therefore its ability to handle complex queries suffers. Most other databases put a lot of energy into preparing, and so it is very important to try to avoid recomp
Re: (Score:1)
Actually I am going to use it on a very very busy site ;) SQL preparing does not make much sense for me since our platform will usually work in the context of PostgreSQL PL/Proxy cluster *AND* the query could be dynamic enough to defeat ordinary DBI param binding.
Actually runtime performance is the reason to choose source-filter solutions in the first place ;)
Also, the SQL example is, well, merely an example...Filter::QuasiQuote's power reveals in the context of true DSLs ;)
Re: (Score:1)
My experience says that with a sane design you can run one of the top couple thousand busiest websites on the internet on a handful of webservers, paying only a modest amount of attention to performance of the code on your webservers.
That same experience says that tiny mistakes in how you handle your database can cause that same site to melt unexpectedly.
The lesson is to not worry about webserver performance, but be paranoid about database performance. Which means use placeholders properly. If you do it d
Re: (Score:1)
I must say that all you say is indeed true for an ordinary web application :)
But unfortunately I can't use prepare+execute in my OpenResty platform in particular. Why? Because it must scale by design to serve lots of apps here in Yahoo! China and Alibaba. So it must be a cluster or something like that.
The PL/Proxy database server requires frontend queries to be of the following form:
select xquery('account', 'select * from posts...', 1);
That is, the user sql query itself must be a dynam
Re:Don’t use that on a high volume site (Score:1)
You are aware of DBD::Gofer [cpan.org] I suppose?
Reply to This
Parent
Re: (Score:1)
Oh, not yet :)) Thanks for the info, I'll try it out to see if it'll fit in my OpenResty architecture :)
Re: (Score:1)
Then be sure to check out the slides from Tim’s OSCON ’07 DBD::Gofer talk [cpan.org].