Re: pgbench doc fix

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: pgbench doc fix
Дата
Msg-id alpine.DEB.2.21.1811020818350.12518@lancre
обсуждение исходный текст
Ответ на Re: pgbench doc fix  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pgbench doc fix  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список pgsql-hackers
Robert,

>> Yes, you need to send params (thus send bind message) anyway.
>> Regarding re-parsing, maybe you mixed up parse-analythis with
>> planning? Re-parse-analythis can only be avoided if you can reuse
>> named (or unnamed) parepared statements.
>
> So given this, I'm struggling to see anything wrong with the current
> wording.

ISTM that the point is not that it is wrong, but it could be more precise.

> I mean, if you say that you are reusing prepared statements,

It does not say "reuse" explicitely, it says

      "prepared: use extended query protocol with prepared statements."

but the extended protocol does always "prepare" statements before 
executing them, the difference are that with "-M prepared" (1) it is done 
just once and (2) named so that it can be indeed reused.

Note that "extended" prepares much more statements than "prepared":-)

> someone will assume that you are avoiding preparing them repeatedly,
> which -M extended will not do ... and by the nature of that approach, 
> cannot do.

Sure. At the protocol level "prepare" is slightly imprecise, and the 
documentation is about the protocol used.

So I do not think a more precise wording harms. Maybe: "prepared: use 
extended query protocol with REUSED named prepared statements" would be 
even less slightly ambiguous.

-- 
Fabien.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Small run-time pruning doc fix
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: wal_dump output on CREATE DATABASE