I think this might be a game changing feature. For the first time after 10 years I have reason to consider MySQL, as the cost per performance in such scenario is amazing. Morever I wont have to run it in single mod or loose other functionality by using this feautre. as I can access the ordinary interface on port 3306 and the fast interface on other port.
I wonder if PostgreSQL should replicate this functionality somehow. How can I represent this idea to the developers? They will probably know if this feature worth something. Thanks, Miki -------------------------------------------------- Michael Ben-Nes - Internet Consultant and Director. http://www.epoch.co.il - weaving the Net. Cellular: 054-4848113 -------------------------------------------------- On Tue, Dec 21, 2010 at 11:07 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > On Tue, Dec 21, 2010 at 10:50 AM, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > > 2010/12/21 Michael Ben-Nes <mich...@epoch.co.il>: > >> Hi Pavel, > >> > >> Thanks for your quick answer. Can you please elaborate a bit more about > the > >> points bellow. > >> > >> On Tue, Dec 21, 2010 at 1:31 PM, Pavel Stehule <pavel.steh...@gmail.com > > > >> wrote: > >>> > >>> Hello > >>> > >>> you can emulate it now. > >>> > >>> a) try to do a simple stored procedure, where you can wrap your query > >> > >> Do you mean I should use PREPARE? > > > > yes > > > >> > >>> b) use a FAST CALL API to call this procedure > >> > >> Currently I use PHP to access the DB which use libpq. Is that cosidered > a > >> fast call API ? if not, can you please refer me to the right info. > >> > >>> > > > > sorry it is a fast-path interface > > > > http://www.postgresql.org/docs/8.1/static/libpq-fastpath.html > > > > but php hasn't a adequate API :( > > > I don't think fastpath interface is going to get you there. What they > are doing with mysql is bypassing both the parser and the protocol. > As soon as you use libpq, you've lost the battle...you can't see > anywhere close to to that performance before you become network > bottlenecked. > > If you want to see postgres doing this in action, you could fire up > the database in single user mode and run raw queries against the > backend. Another way to do it is to hack tcop/postgres.c and inject > protocol messages manually. Right now, the only way to get that close > to the metal using standard techniques is via SPI (plpgsql, etc). A > proper transaction free stored procedure implementation would open a > lot of doors for fast query execution. > > merlin > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance >
