On Mon, Sep 29, 2014 at 12:05 PM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers