Hi,
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.
https://commitfest.postgresql.org/7/418/
https://github.com/2ndQuadrant/postgres/tree/dev/pglogical-output
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
