Re: [HACKERS] libpq Alternate Row Processor

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: [HACKERS] libpq Alternate Row Processor
Дата
Msg-id ea7c7c9f-be95-e955-b4c8-c6e077d5db94@BlueTreble.com
обсуждение исходный текст
Ответ на Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Ответы Re: [HACKERS] libpq Alternate Row Processor  (Kyle Gearhart <kyle.gearhart@indigohill.io>)
Список pgsql-hackers
On 2/8/17 5:11 PM, Kyle Gearhart wrote:
> Overall, wall clock improves 24%.  User time elapsed is a 430% improvement.  About half the time is spent waiting on
theIO with the callback.  With the regular pqRowProcessor only about 16% of the time is spent waiting on IO.
 

To wit...
    real    user    sys
single row    0.214    0.131    0.048
callback    0.161    0.030    0.051

Those are averaged over 11 runs.

Can you run a trace to see where all the time is going in the single row 
case? I don't see an obvious time-suck with a quick look through the 
code. It'd be interesting to see how things change if you eliminate the 
filler column from the SELECT.

Also, the backend should be buffering ~8kb of data before handing that 
to the socket. If that's more than the kernel can buffer I'd expect a 
serious performance hit.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)



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

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] [PATCH] Rename pg_switch_xlog to pg_switch_wal