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
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 |