Re: Performance Enhancement/Fix for Array Utility Functions

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
mikelikespie(at)gmail(dot)com

On Thu, Aug 5, 2010 at 10:52 AM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> > On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis
> > <mikelikespie(at)gmail(dot)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
>