Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..

Поиск
Список
Период
Сортировка
От Tobias Oberstein
Тема Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Дата
Msg-id a7fc2477-d9d6-c695-b40a-76ad341562c9@gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Hi,

>> Synthetic PG workload or real world production workload?
>
> Both might work, production-like has bigger pull, but I'd guess
> synthetic is good enough.

Thanks! The box should get PostgreSQL in the not too distant future. 
It'll get a backup from prod, but will act as new prod, so it might take 
some time until a job can be run and a profile collected.

>> So how would I do a perf profile that would be acceptable as prove?
>
> You'd have to look at cpu time, not number of syscalls.  IIRC I
> suggested doing a cycles profile with -g and then using "perf report
> --children" to see how many cycles are spent somewhere below lseek.

Understood. Either profile manually or expand the function.

> I'd also suggest sharing a profile cycles profile, it's quite likely
> that the overhead is completely elsewhere.

Yeah, could be. It'll be interesting to see for sure. I should get a 
chance to collect such profile and then I'll post it back here -

/Tobias




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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Checksums by default?
Следующее
От: Nikita Glukhov
Дата:
Сообщение: Re: [HACKERS] PATCH: recursive json_populate_record()