On Sun, Jul 31, 2016 at 4:05 PM, Shay Rojansky <roji@roji.org> wrote:
> I'm well aware of how the extended protocol works, but it seems odd for a
> 30% increase in processing time to be the result exclusively of processing 5
> messages instead of just 1 - it doesn't seem like that big a deal (although
> I may be mistaken). I was imagining that there's something more fundamental
> in how the protocol or PostgreSQL state is managed internally, that would be
> responsible for the slowdown.
I think you're looking at this the wrong way around. 30% of what?
You're doing these simple read-only selects on a database that
obviously is entirely in RAM. If you do the math on the numbers you
gave above the simple protocol took 678 microseconds per transaction
and the extended protocol took 876 microseconds. The difference is 198
microseconds. I'm not sure exactly where those 200us are going and
perhaps it could be lower but in what real-world query is it going to
have a measurable impact on the total time?
The other danger in unrealistic test cases is that you're probably
measuring work that doesn't scale and in fact optimizing based on it
could impose a cost that *does* scale. For example if 150us of that
time is being spent in the prepare and we cut that down by a factor of
10 to 15us then it would be only a 10% penalty over the simple
protocol in your test. But if that optimization added any overhead to
the execute stage then when it's executed thousands of times that
could add milliseconds to the total runtime.
--
greg
