Re: Slowness of extended protocol

Поиск
Список
Период
Сортировка
От Shay Rojansky
Тема Re: Slowness of extended protocol
Дата
Msg-id CADT4RqBt7trfp8UzR5KKv7=gRse5P9_yuGGdczsnY+UVqp5CdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slowness of extended protocol  (Vladimir Sitnikov <sitnikov.vladimir@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Combining hash values
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Hash indexes and effective_cache_size in CREATE INDEX documentation