Re: computing completion tag is expensive for pgbench -S -M prepared
От | Simon Riggs |
---|---|
Тема | Re: computing completion tag is expensive for pgbench -S -M prepared |
Дата | |
Msg-id | CANP8+j+z_pHzQe_nCxo2LhS9+dCc-R9KkiwuzZ-ZnL4wxyZBPw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: computing completion tag is expensive for pgbench -S -M prepared (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: computing completion tag is expensive for pgbench -S -M prepared
|
Список | pgsql-hackers |
On 7 June 2018 at 19:20, Andres Freund <andres@anarazel.de> wrote: > On 2018-06-07 11:40:48 +0100, Simon Riggs wrote: >> On 7 June 2018 at 11:29, Pavel Stehule <pavel.stehule@gmail.com> wrote: >> >> >> Do we actually need the completion tag at all? In most cases?? >> > >> > >> > affected rows is taken from this value on protocol level >> >> I didn't mean we should remove the number of rows. Many things rely on that. > > How do you mean it then? We can't really easily change how we return > that value on the protocol level, and the command tag is basically just > returned as a string in the protocol. If we were to design the protocol > today I'm sure we just would declare the rowcount and affected rowcounts > separate fields or something, but ... I meant remove the pointless noise word at the start of the tag that few clients care about. I was thinking of just returning "SQL" instead, but that wasn't after much thought. But now I think about it more returning any fixed string, "SQL" or "SELECT", in the protocol seems like a waste of bandwidth and a potential route in to decrypt the stream. If we're going to compress the protocol, it seems sensible to remove extraneous information first. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: