On Tue, Dec 21, 2010 at 10:50 AM, Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote: > 2010/12/21 Michael Ben-Nes <michael@xxxxxxxxxxx>: >> 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.stehule@xxxxxxxxx> >> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
