Re: Slowness of extended protocol - Mailing list pgsql-hackers

From Shay Rojansky
Subject Re: Slowness of extended protocol
Date
Msg-id CADT4RqBt7trfp8UzR5KKv7=gRse5P9_yuGGdczsnY+UVqp5CdQ@mail.gmail.com
Whole thread Raw
In response to Re: Slowness of extended protocol  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
List pgsql-hackers
Shay Rojansky <roji@roji.org>:
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.

Hi, have you tried to use a profiler to identify the _cause_ of the difference in performance?


I'm definitely not a stage where I'm interested in the cause of the difference. I'm not a PostgreSQL hacker, and I'm not going into the source code to try and optimize anything (not yet anyway). For now, I'm just looking to get a high-level picture of the situation and to inform people that there may be an issue.

Or in terms of your article, I'm plugging a light bulb into the wall socket and the light is dim, so I'm trying to ask the building electricity team if they're aware of it, if if it's a fixable situation and if there are plans to fix it - before pushing any fingers into some electricity cabinet I don't know.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Combining hash values
Next
From: Tom Lane
Date:
Subject: Re: Hash indexes and effective_cache_size in CREATE INDEX documentation