On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost <sfrost@snowman.net> wrote:
> Perhaps I'm just being a bit over the top, but all this per-character
> work feels a bit ridiculous.. When we're using MAXIMUM_ALIGNOF, I
> suppose it's not so bad, but is there no hope to increase that and make
> this whole process more efficient? Just a thought.
I'm not sure I understand what you're getting at here.
> After reading through the code for 0001, I decided to actually take it
> out for a spin- see attached. I then passed a few megabytes of data
> through it and it seemed to work just fine.
That's good.
> In general, I'm quite excited about this capability and will be looking
> over the later patches also. I also prefer the function-pointer based
> approach which was taken up in later versions to the hook-based approach
> in the initial patches, so glad to see things going in that direction.
OK.
> Lastly, I will say that I feel it'd be good to support bi-directional
> communication as I think it'll be needed eventually, but I'm not sure
> that has to happen now.
I agree we need bidirectional communication; I just don't agree that
the other direction should use the libpq format. The data going from
the worker to the process that launched it is stuff like errors and
tuples, for which we already have a wire format. The data going in
the other direction is going to be things like plan trees to be
executed, for which we don't. But if we can defer the issue, so much
the better. Things will become clearer as we get closer to being
done.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
