Re: stats for network traffic WIP

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: stats for network traffic WIP
Дата
Msg-id 77004405-D3E9-4DCC-9E04-9D69916D9725@gmail.com
обсуждение исходный текст
Ответ на Re: stats for network traffic WIP  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers

Sent from my iPad

> On 07-Dec-2013, at 23:47, Fujii Masao <masao.fujii@gmail.com> wrote:
>
>> On Wed, Nov 20, 2013 at 3:18 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>>> On Tue, Nov 19, 2013 at 11:43 PM, Mike Blackwell <mike.blackwell@rrd.com> wrote:
>>> This patch looks good to me.  It applies, builds, and runs the regression
>>> tests.  Documentation is included and it seems to do what it says.  I don't
>>> consider myself a code expert, but as far as I can see it looks fine.  This
>>> is a pretty straightforward enhancement to the existing pg_stat_* code.
>>>
>>> If no one has any objections, I'll mark it ready for committer.
>>>
>>> Mike
>>
>> I agree.
>>
>> I had a discussion with Mike yesterday, and took the performance areas
>> in the patch. I think the impact would be pretty low and since the
>> global counter being incremented is incremented with keeping race
>> conditions in mind, I think that the statistics collected will be
>> valid.
>>
>> So, I have no objections to the patch being marked as ready for committer.
>
> Could you share the performance numbers? I'm really concerned about
> the performance overhead caused by this patch.
I did some pgbench tests specifically with increasing number of clients, as that are the kind of workloads that can
leadto display in slowness due to increase in work in the commonly used functions. Let me see if I can get the numbers
andsee where I kept them. 

>
> Here are the comments from me:
>
> All the restrictions of this feature should be documented. For example,
> this feature doesn't track the bytes of the data transferred by FDW.
> It's worth documenting that kind of information.

+1

>
> ISTM that this feature doesn't support SSL case. Why not?
>
> The amount of data transferred by walreceiver also should be tracked,
> I think.
>
Yes, I agree. WAL receiver data transfer can be problematic some times as well, so should be tracked.

Regards,

Atri


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: stats for network traffic WIP
Следующее
От: Thom Brown
Дата:
Сообщение: Index overhead cost reporting