Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Дата
Msg-id CAA4eK1LUrRNQmHs=pFe4R_9R68gJ_54ZXUm23T5vg=JmRpqf6Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Mahendra Singh Thalor <mahi6run@gmail.com>)
Ответы Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions  (Mahendra Singh Thalor <mahi6run@gmail.com>)
Список pgsql-hackers
On Wed, May 27, 2020 at 5:19 PM Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
On Tue, 26 May 2020 at 16:46, Amit Kapila <amit.kapila16@gmail.com> wrote:

Hi all,
On the top of v16 patch set [1], I did some testing for DDL's and DML's to test wal size and performance. Below is the testing summary;

Test parameters:
wal_level= 'logical
max_connections = '150'
wal_receiver_timeout = '600s'
max_wal_size = '2GB'
min_wal_size = '2GB'
autovacuum= 'off'
checkpoint_timeout= '1d'

Test results:

CREATE index operationsAdd col int(date) operationsAdd col text operations
SN.operation nameLSN diff (in bytes)time (in sec)% LSN changeLSN diff (in bytes)time (in sec)% LSN changeLSN diff (in bytes)time (in sec)% LSN change
1
1 DDL without patch177280.89116
1.624548
9760.764393
11.475409
339040.80044
2.80792
with patch180160.80486810880.763602348560.787108
2
2 DDL without patch198720.860348
2.73752
16320.763199
13.7254902
345600.806086
3.078703
with patch204160.83906518560.733147356240.829281
3
3 DDL without patch220160.894891
3.63372093
22880.776871
14.685314
352160.803493
3.339391186
with patch228160.82802826240.737177363920.800194
4
4 DDL without patch241600.901686
4.4701986
29440.768445
15.217391
358720.77489
3.590544
with patch252400.88714333920.768382371600.82777
5
5 DDL without patch263280.901686
4.9832877
36000.751879
15.555555
365280.817928
3.832676
with patch276400.91407841600.74709379280.820621
6
6 DDL without patch284720.936385
5.5071649
42560.745179
15.78947368
371840.797043
4.066265
with patch300400.95822649280.725321386960.814535
7
8 DDL without patch327601.0022203
6.422466
55680.757468
16.091954
384960.83207
4.509559
with patch348640.96677764640.769072402320.903604
8
11 DDL without patch502961.0022203
5.662478
75360.748332
16.666666
404640.822266
5.179913
with patch531440.96677787920.750553425600.797133
9
15 DDL without patch588961.267253
5.662478
101840.776875
16.496465
431120.821916
5.84524
with patch627681.27234118640.746844456320.812567
10
1 DDL & 3 DML without patch182400.812551
1.6228
11920.771993
10.067114
341200.849467
2.8113599
with patch185360.81908913120.785117350800.855456
11
3 DDL & 5 DML without patch236560.926616
3.4832606
26560.758029
13.55421687
355840.829377
3.372302
with patch244800.91551730160.797206367840.839176
12
10 DDL & 5 DML without patch527601.101005
4.958301744
72880.763065
16.02634468
402160.837843
4.993037
with patch553761.10524184560.779257422240.835206
13
10 DML without patch10080.791091
6.349206
10080.81105
6.349206
10080.78817
6.349206
with patch10720.80787510720.77111310720.759789

To see all operations, please see[2] test_results


Why are you seeing any additional WAL in case-13 (10 DML) where there is no DDL?  I think it is because you have used savepoints in that case which will add some additional WAL.  You seems to have 9 savepoints in that test which should ideally generate 36 bytes of additional WAL (4-byte per transaction id for each subtransaction).  Also, in other cases where you took data for DDL and DML, you have also used savepoints in those tests. I suggest for savepoints, let's do separate tests as you have done in case-13 but we can do it 3,5,7,10 savepoints and probably each transaction can update a row of 200 bytes or so.

I think you can take data for somewhat more realistic cases of DDL and DML combination like 3 DDL's with 10 DML and 3 DDL's with 15 DML operations.  In general, I think we will see many more DML's per DDL.  It is good to see the worst-case WAL and performance overhead as you have done.

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

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of largein-progress transactions
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: OpenSSL 3.0.0 compatibility