Re: Slowness of extended protocol

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Shay Rojansky <roji(at)roji(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Slowness of extended protocol
Date: 2016-08-05 13:53:09
Message-ID: CA+TgmoaR0OQ3Zes3qfUC8fSaHc4CTs8gqK3dJXX2wTa_+SEH7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 3, 2016 at 7:35 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> On Wed, Aug 3, 2016 at 10:02:39AM -0400, Tom Lane wrote:
>> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote:
>> >> In hindsight it seems clear that what a lot of apps want out of extended
>> >> protocol is only the ability to send parameter values out-of-line instead
>> >> of having to quote/escape them into SQL literals. Maybe an idea for the
>> >> fabled V4 protocol update is some compromise query type that corresponds
>> >> precisely to PQexecParams's feature set: you can send parameter values
>> >> out-of-line, and you can specify text or binary results, but there's no
>> >> notion of any persistent state being created and no feedback about
>> >> parameter data types.
>>
>> > Do you want this on the TODO list?
>>
>> I didn't hear anyone say it was a silly idea, so sure.
>
> Done:
>
> Create a more efficient way to handle out-of-line parameters

FWIW, I agree with this idea.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-08-05 13:54:11 Re: [RFC] Change the default of update_process_title to off
Previous Message Bruce Momjian 2016-08-05 13:52:25 Re: Heap WARM Tuples - Design Draft