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
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
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
On Fri, Jul 16, 2010 at 4:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Daniel Farina drfar...@acm.org 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
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
Daniel Farina drfar...@acm.org 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
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 mikelikes...@gmail.com 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.
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
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 mikelikes...@gmail.com wrote:
I noticed while doing
On Wed, Mar 31, 2010 at 5:08 AM, Mike Lewis mikelikes...@gmail.com 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
On Wed, Mar 31, 2010 at 8:28 AM, Robert Haas robertmh...@gmail.com 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
12 matches
Mail list logo
