Greg Smith <g...@2ndquadrant.com> wrote: > After getting off to a good start, it looks like this patch is now > stuck waiting for a second review pass from Kevin right now, with > no open items for Andres to correct. Since the only issues on the > table seem to be that of code aesthetics and long-term planning > for this style of implementation rather than specific functional > bits, I'm leaning toward saying this one is ready to have a > committer look at it. Any comments from Kevin or Andres about > where this is at? Yeah, really the only thing I found to complain about was one misspelled word in a comment. I am currently the hold-up, due to fighting off a bout of some virus and having other "real world" issues impinge. The only thing left to do, besides correcting the spelling, is to confirm the author's performance improvements and confirm that there is no degradation in a non-targeted situation. Frankly, I'd be amazed if there was a performance regression, because all it really does is pass a pointer to a new spot in an existing input buffer rather than allocating new space and copying the input from the desired spot to the end of the buffer. I can't think of any situations where calculating the new address should be slower than calculating the new address and copying from there to the end of the buffer. -Kevin
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
