Re: Speed up Clog Access by increasing CLOG buffers

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Speed up Clog Access by increasing CLOG buffers
Дата
Msg-id CAA4eK1LtcAOoiSZBLfLs4Ny+g6sUxjxwayN5ACU0DHhDD=2tfQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Speed up Clog Access by increasing CLOG buffers  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Список pgsql-hackers
On Mon, Apr 4, 2016 at 8:55 PM, Jesper Pedersen <jesper.pedersen@redhat.com> wrote:
On 04/01/2016 04:39 PM, Andres Freund wrote:
On April 1, 2016 10:25:51 PM GMT+02:00, Jesper Pedersen <jesper.pedersen@redhat.com> wrote:
Hi,

On 03/31/2016 06:21 PM, Andres Freund wrote:
On March 31, 2016 11:13:46 PM GMT+02:00, Jesper Pedersen
<jesper.pedersen@redhat.com> wrote:

I can do a USE_CONTENT_LOCK run on 0003 if it is something for 9.6.

Yes please. I think the lock variant is realistic, the lockless did
isn't.


I have done a run with -M prepared on unlogged running 10min per data
point, up to 300 connections. Using data + wal on HDD.

I'm not seeing a difference between with and without USE_CONTENT_LOCK
--
all points are within +/- 0.5%.

Let me know if there are other tests I can perform

How do either compare to just 0002 applied?


0001 + 0002 compared to 0001 + 0002 + 0003 (either way) were pretty much the same +/- 0.5% on the HDD run.


I think the main reason why there is no significant gain shown in your tests is that on the m/c where you are testing the contention due to CLOGControlLock is not high enough that any reduction on the same will help.  To me, it is visible in some of the high-end machines like which have 4 or more sockets.  So, I think these results should be taken as an indication that there is no regression in the tests performed by you.

Thanks for doing all the tests for these patches.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Add trigonometric functions that work in degrees.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: snapshot too old, configured by time