Re: BUG #13484: Performance problem with logical decoding

From: Andres Freund <andres(at)anarazel(dot)de>
To: olivier(dot)gosseaume(at)free(dot)fr,pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #13484: Performance problem with logical decoding
Date: 2015-07-03 19:14:29
Message-ID: DAE4FF93-DB6B-439A-A287-4CCB5068599A@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On July 3, 2015 11:02:17 AM GMT+02:00, olivier(dot)gosseaume(at)free(dot)fr wrote:
>The following bug has been logged on the website:
>
>Bug reference: 13484
>Logged by: Olivier Gosseaume
>Email address: olivier(dot)gosseaume(at)free(dot)fr
>PostgreSQL version: 9.4.4
>Operating system: Windows 7 64 bits (dev system)
>Description:
>
>Problem: when a transaction involve more than 4095 operations, logical
>decoding on the receiver end become very very slow.

Around 4096 transactions are getting spilled to disk.

>Repro :
>Open two psql sessions 1 and 2
>
>On session 1 :
>Prepare :
>CREATE TABLE data(id serial primary key, data text);
>
>On session 2 (receiver) :
>Prepare :
>\timing on
>SELECT pg_create_logical_replication_slot('my_slot','test_decoding');
>
>Run :
>On session 1 : insert into data (data) values
>(generate_series(1,4095));
>On session 2 : select pg_logical_slot_get_changes('my_slot', NULL,
>NULL);
>--> returns in 80mS (plenty fast)
>
>On session 1 : insert into data (data) values
>(generate_series(1,4095)); -->
>repeat this 10 times to insert 40950 rows
>On session 2 : select pg_logical_slot_get_changes('my_slot', NULL,
>NULL);
>--> returns in 380mS (plenty fast)

That's less than linear growth...

>Now the problem :
>On session 1 : insert into data (data) values
>(generate_series(1,4096));
>On session 2 : select pg_logical_slot_get_changes('my_slot', NULL,
>NULL);
>--> returns in 4204mS (ie 52x times slower than "normal")

So you just had 4096 changes here?

>On session 1 : insert into data (data) values
>(generate_series(1,40950));
>On session 2 : select pg_logical_slot_get_changes('my_slot', NULL,
>NULL);
>--> returns in 34998mS (ie 92x times slower than "normal")

The SQL interface isn't really the best thing to test this - the output as a whole is stored first in memory, and then when getting to large, spilled to disk. Additionally the starting/stopping of the slot can take a long while because EAL may need to be reread.

Please test the same using the streaming interface. You can use pg-recvlogical.

Regards,

Andres

---
Please excuse brevity and formatting - I am writing this on my mobile phone.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bailu Ding 2015-07-03 20:57:45 Re: BUG #13481: No config folder upon installation
Previous Message David G. Johnston 2015-07-03 18:53:44 Re: BUG #13485: JSONB To recordset not working with CamelCase