Re: Postgres-R: primary key patches

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: chris <cbbrowne(at)ca(dot)afilias(dot)info>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Postgres-R: primary key patches
Date: 2008-07-21 08:40:02
Message-ID: 48844B62.7050003@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Alvaro Herrera wrote:
> Markus Wanner wrote:
>> (Although, I'm still less than thrilled about the internal storage
>> format of these tuple collections. That can certainly be improved and
>> simplified.)
>
> Care to expand more on what it is?

Well, what I really dislike is the overhead in code to first transform
tuples into a string based internal change set representation, which
then gets serialized again. That looks like two conversion steps, which
are both prone to error.

I'm about to merge those into a simpler tuple serializer, which shares
code with the initializer (or recovery provider/subscriber) part. This
is where I'd like to know what requirements Jan or others have. I will
try to outline the current implementation and requirements of Postgres-R
in a new thread soon.

> On Replicator we're using the binary
> send/recv routines to transmit tuples. (Obviously this fails when the
> master and slave have differing binary output, but currently we just
> punt on this point).

Yeah, that's another point. I'm currently using the textual input/output
functions, but would like to switch to the binary one as well. However,
that's an optimization, where the above is simplification of code, which
is more important to me at the moment.

Regards

Markus

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2008-07-21 08:53:08 Default of max_stack_depth and getrlimit
Previous Message Tom Lane 2008-07-21 07:43:11 Re: pg_dump lock timeout