* Robert Haas (robertmhaas@gmail.com) wrote:
> 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.
Was just thinking that we might be able to work out what needs to be
done without having to actually do it on a per-character basis. That
said, I'm not sure it's really worth the effort given that we're talking
about at most 8 bytes currently. I had originally been thinking that we
might increase the minimum size as it might make things more efficient,
but it's not clear that'd really end up being the case either and,
regardless, it's probably not worth worrying about at this point.
> > 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.
Just to note this- the testing which I did used a random number of
segments and random amounts of data with each and hit specific edge
cases and all looked good.
> > 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.
Sounds good to me.
Thanks,
Stephen