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
differ
Robert Haas wrote:
> On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis
> 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 toaste
On Wed, Jul 28, 2010 at 1:20 AM, Mike Lewis 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
>
>
> > 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 s
On Fri, Jul 16, 2010 at 4:43 PM, Tom Lane wrote:
> Daniel Farina writes:
>> Generally I think the delimited untoasting of metadata from arrays
>> separately from the payload is Not A Bad Idea.
>
> I looked at this patch a bit. I agree that it could be a big win for
> large external arrays, but .
Daniel Farina writes:
> Generally I think the delimited untoasting of metadata from arrays
> separately from the payload is Not A Bad Idea.
I looked at this patch a bit. I agree that it could be a big win for
large external arrays, but ...
1. As-is, it's a significant *pessimization* for small
>
>
> The existence and naming of ARR_MAX_HEADER_SIZE is somewhat dubious,
> as it is:
>
Thanks you for the feedback. I cleaned up the patch.
> * Used in exactly one place (not necessarily a reason why it should
> not be reified into a stand-alone definition, though, but
> something to consider
On Wed, Mar 31, 2010 at 9:47 AM, Mike Lewis wrote:
> Thanks. Added it.
>
> https://commitfest.postgresql.org/action/patch_view?id=292
I have reviewed this patch; this is my review:
Regression tests pass with assertions enabled.
Performance gains reported by author confirmed.
The existence and
On Wed, Mar 31, 2010 at 8:28 AM, Robert Haas wrote:
>
> Neat. Please add it here:
>
> https://commitfest.postgresql.org/action/commitfest_view/open
>
> ...Robert
>
Thanks. Added it.
https://commitfest.postgresql.org/action/patch_view?id=292
-Mike
--
Sent via pgsql-hackers mailing list (pgsql
On Wed, Mar 31, 2010 at 5:08 AM, Mike Lewis wrote:
> Woops. I sent the wrong patch. My apologies. Attached is the real
> patch. Sorry, also forgot this is made against 9.0 alpha 4 tag.
Neat. Please add it here:
https://commitfest.postgresql.org/action/commitfest_view/open
...Robert
--
Sent
Woops. I sent the wrong patch. My apologies. Attached is the real
patch. Sorry, also forgot this is made against 9.0 alpha 4 tag.
Thanks,
Mike
--
Michael Lewis
lolrus.org
mikelikes...@gmail.com
On Wed, Mar 31, 2010 at 12:39 AM, Mike Lewis wrote:
> I noticed while doing work with very large
I noticed while doing work with very large arrays that several
functions such as array_length detoast the entire array instead of
only what is required.
I found the solution to be just unpacking the header portion of the
array and ignoring the rest. Since the header (including the
dimensions) is
12 matches
Mail list logo
