I have integrated pglogical_output in multimaster, using bdr_apply from BDR as 
template for implementation of receiver part.
The time of insert is reduced almost 10 times comparing with logical 
replication based on decoder_raw/receiver_raw plugins which performs logical 
replication using SQL statements. But unfortunately time of updates is almost 
not changed.
It is expected result because I didn't see any functions related with SQL 
parsing/preparing in profile.
Now in both cases profile is similar:

  4.62%  postgres                            [.] HeapTupleSatisfiesMVCC
  2.99%  postgres                            [.] heapgetpage
  2.10%  postgres                            [.] hash_search_with_hash_value
  1.86%  postgres                            [.] ExecProject
  1.80%  postgres                            [.] heap_getnext
  1.79%  postgres                            [.] PgXidInMVCCSnapshot

By the way, you asked about comments concerning pglogical_output. I have one: most of 
pglogical protocol functions have "PGLogicalOutputData *data" parameter. There 
are few exceptions:

    write_startup_message_fn, pglogical_write_origin_fn, pglogical_write_rel_fn

PGLogicalOutputData is the only way to pass protocol specific data, using 
"PGLogicalProtoAPI *api" field.
This field is assigned by  pglogical_init_api() function. And I can extend this 
PGLogicalProtoAPI structure by adding some protocol specific fields.
For example, this is how it is done now for multimaster:

typedef struct PGLogicalProtoMM
    PGLogicalProtoAPI api;
    bool isLocal; /* mark transaction as local */
} PGLogicalProtoMM;

PGLogicalProtoAPI *
pglogical_init_api(PGLogicalProtoType typ)
    PGLogicalProtoMM* pmm = palloc0(sizeof(PGLogicalProtoMM));
    PGLogicalProtoAPI* res = &pmm->api;
    pmm->isLocal = false;
    res->write_rel = pglogical_write_rel;
    res->write_begin = pglogical_write_begin;
    res->write_commit = pglogical_write_commit;
    res->write_insert = pglogical_write_insert;
    res->write_update = pglogical_write_update;
    res->write_delete = pglogical_write_delete;
    res->write_startup_message = write_startup_message;
    return res;

But I have to add "PGLogicalOutputData *data"  parameter to 
pglogical_write_rel_fn function.
Di you think that it will be better to pass this parameter to all functions?

May be it is not intended way of passing custom data to this functions...
Certainly it is possible to use static variables for this purpose.
But I think that passing user specific data through PGLogicalOutputData is 
safer and more flexible solution.

On 12/03/2015 04:53 PM, Craig Ringer wrote:
On 3 December 2015 at 19:06, konstantin knizhnik <k.knizh...@postgrespro.ru 
<mailto:k.knizh...@postgrespro.ru>> wrote:

    On Dec 3, 2015, at 10:34 AM, Craig Ringer wrote:

    On 3 December 2015 at 14:54, konstantin knizhnik <k.knizh...@postgrespro.ru 
<mailto:k.knizh...@postgrespro.ru>> wrote:

        I'd really like to collaborate using pglogical_output if at all 
possible. Petr's working really hard to get the pglogical downstrem out too, 
with me helping where I can.
        And where I can get  pglogical_output plugin? Sorry, but I can't 
quickly find reference with Google...

    It's been submitted to this CF.



    Any tests and comments would be greatly appreciated.

    Thank you.
    I wonder if there is opposite part of the pipe for pglogical_output - 
analog of receiver_raw?

It's pglogical, and it's in progress, due to be released at the same time as 
9.5. We're holding it a little longer to nail down the user interface a bit 
better, etc, and because sometimes the real world gets in the way.

The catalogs and UI are very different to BDR, it's much more extensible/modular, it supports much more flexible topologies, etc... but lots of the core concepts are very similar. So if you go take a look at the BDR code that'll give you a pretty solid idea of how a lot of it works, though BDR has whole subsystems pglogical doesn't (global ddl lock, ddl replication, etc).
 Craig Ringer http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Reply via email to