Re: MySQL HandlerSocket - Is this possible in PG? - Mailing list pgsql-performance
| From | Michael Ben-Nes |
|---|---|
| Subject | Re: MySQL HandlerSocket - Is this possible in PG? |
| Date | |
| Msg-id | AANLkTikkg5R9QP3rzhFRvGLAAhYqjsyWqD6+YJHYyo9S@mail.gmail.com Whole thread Raw |
| In response to | Re: MySQL HandlerSocket - Is this possible in PG? (Merlin Moncure <mmoncure@gmail.com>) |
| Responses |
Re: MySQL HandlerSocket - Is this possible in PG?
(Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
|
| List | pgsql-performance |
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
--------------------------------------------------
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@gmail.com> wrote:
On Tue, Dec 21, 2010 at 10:50 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:I don't think fastpath interface is going to get you there. What they
> 2010/12/21 Michael Ben-Nes <michael@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.stehule@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 :(
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
pgsql-performance by date: