Re: MySQL HandlerSocket - Is this possible in PG?

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 <mmoncure(at)gmail(dot)com> wrote:

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