On Sun, Jul 31, 2016 at 4:05 PM, Shay Rojansky <r...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
