I started taking a look at the internals of the detoast functions and I came to the conclusion that I didn't have sufficient understanding of what was going on to make the correct changes, nor sufficient time to gain that understanding. Sorry for not getting back sooner. There are a lot of different cases for the detoast stuff, and I think I would need a full understanding of toast functionality. (for example, I didn't even know there was lzma compression in postgres until one of the replies to this thread)
Thanks, Mike -- Michael Lewis lolrus.org mikelikes...@gmail.com On Thu, Aug 5, 2010 at 10:52 AM, Kevin Grittner <kevin.gritt...@wicourts.gov > wrote: > Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis > > <mikelikes...@gmail.com> wrote: > >>> > >>> > 1. As-is, it's a significant *pessimization* for small arrays, > >>> > because the heap_tuple_untoast_attr_slice code does a > >>> > palloc/copy even when one is not needed because the data is > >>> > already not toasted. I think there needs to be a code path > >>> > that avoids that. > >>> > >>> This seems like it shouldn't be too hard to fix, and I think it > >>> should be fixed. > >> > >> Do you have any suggestions where to start? I do agree that this > >> should be fixed as well. I don't have too much time to dedicate > >> to this project. I can try to put in some time this weekend > >> though if it isn't looking too bad. > > > > Perhaps you could check VARATT_IS_EXTENDED. If that's true, then > > slice it, but if it's false, then just use the original datum. > > You might want to wrap that up in a function rather than cramming > > it all in the macro definition, though. > > As Mike hasn't been able to find the time to get to this yet, I'm > marking this as "Returned with Feedback". Hopefully the issues can > be addressed in the next five weeks and we can pick it up again in > the next CommitFest. > > -Kevin >
