Andres Freund writes:
> On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
>> It is, but why would it be a disaster? We could add StaticAsserts
>> verifying that the sizes actually are different. I doubt that the pad
>> space itself could amount to any issue performance-wise, since it would
>> only e
On 2015-05-13 21:01:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
> >> I still think that going back to defining the second byte as the size
> >> would be better. Fortunately, since this is only a matter of in-memory
> >> representations, we a
Andres Freund writes:
> On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
>> I still think that going back to defining the second byte as the size
>> would be better. Fortunately, since this is only a matter of in-memory
>> representations, we aren't committed to any particular answer.
> Requiring s
On 2015-05-13 20:48:51 -0400, Tom Lane wrote:
> I still think that going back to defining the second byte as the size
> would be better. Fortunately, since this is only a matter of in-memory
> representations, we aren't committed to any particular answer.
Requiring sizes to be different still str
Andres Freund writes:
> On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
>> Andres Freund writes:
>>> * The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
>>> beneficial, before the compiler could implement the whole thing as a
>>> computed goto or lookup table, afterwards not.
>> Well
On 2015-05-13 20:28:52 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Similarly using inline funcs for AARR_NDIMS/HASNULL does not appear to
> > hamper performance and gets rid of the multiple evaluation risk.
>
> I'm less excited about that part though. The original ARR_FOO macros
> mostly
Andres Freund writes:
> On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
>>> * I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't
>>> buy the argument that turning them into functions will be slower. I'd
>>> bet the contrary on common platforms.
>> Perhaps; do you want to do some
On 2015-05-10 21:09:14 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I'm not sure what exactly to use as a performance benchmark
> > here. For now I chose
> > SELECT * FROM (SELECT ARRAY(SELECT generate_series(1, 1))) d,
> > generate_series(1, 1000) repeat(i);
> > that'll hit array_out,
Andres Freund writes:
> I'm not sure what exactly to use as a performance benchmark
> here. For now I chose
> SELECT * FROM (SELECT ARRAY(SELECT generate_series(1, 1))) d,
> generate_series(1, 1000) repeat(i);
> that'll hit array_out, which uses iterators.
Hmm, probably those results are swa
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
> > * I find the ARRAY_ITER_VARS/ARRAY_ITER_NEXT macros rather ugly. I don't
> > buy the argument that turning them into functions will be slower. I'd
> > bet the contrary on common platforms.
> Perhaps; do you want to do some testing and see?
I'v
On 2015-05-10 12:09:41 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Looking at this. First reading the patch to understand the details.
>
> > * The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
> > beneficial, before the compiler could implement the whole thing as a
> > co
Andres Freund writes:
> Looking at this. First reading the patch to understand the details.
> * The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
> beneficial, before the compiler could implement the whole thing as a
> computed goto or lookup table, afterwards not.
Well, if you
Hi,
> The attached updated patch reduces both of those do-loop tests to about
> 60 msec on my machine. It contains two improvements over the 1.1 patch:
Looking at this. First reading the patch to understand the details.
* The VARTAG_IS_EXPANDED(tag) trick in VARTAG_SIZE is unlikely to
benefic
2015-05-06 18:54 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > 2015-05-06 15:50 GMT+02:00 Tom Lane :
> >> Another way to look at it is that in this example, plpgsql's attempts to
> >> force the "a" array into expanded form are a mistake: we never get any
> >> benefit because array_cat() just w
Pavel Stehule writes:
> 2015-05-06 15:50 GMT+02:00 Tom Lane :
>> Another way to look at it is that in this example, plpgsql's attempts to
>> force the "a" array into expanded form are a mistake: we never get any
>> benefit because array_cat() just wants it in flat form again, and delivers
>> it in
2015-05-06 15:50 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > Multidimensional append is slower 2x .. but it is probably corner case
>
> > declare a int[] := '{}'; begin for i in 1..9 loop a := a || ARRAY[[i
> > ]]; end loop; raise notice '%', 'aa'; end$$ language plpgsql;
>
> Yeah, that'
Pavel Stehule writes:
> Multidimensional append is slower 2x .. but it is probably corner case
> declare a int[] := '{}'; begin for i in 1..9 loop a := a || ARRAY[[i
> ]]; end loop; raise notice '%', 'aa'; end$$ language plpgsql;
Yeah, that's array_cat(), which I've not done anything with.
2015-05-06 0:50 GMT+02:00 Tom Lane :
> I wrote:
> > Pavel Stehule writes:
> >> Significant slowdown is on following test:
>
> >> do $$ declare a int[] := '{}'; begin for i in 1..9 loop a := a ||
> 10;
> >> end loop; end$$ language plpgsql;
> >> do $$ declare a numeric[] := '{}'; begin for i i
Pavel Stehule writes:
> Some slowdown is visible (about 10%) for query
> update foo set a = a || 1;
> Significant slowdown is on following test:
> do $$ declare a int[] := '{}'; begin for i in 1..9 loop a := a || 10;
> end loop; end$$ language plpgsql;
> do $$ declare a numeric[] := '{}'; b
Hi
I did some test with unlogged table in shared buffers
foo(a int[]); -- 2K long array 100K rows
for queries
select max(v) from (unnest(a) from foo) x;
select max(a[1]) from foo
select max(a[2000]) from foo
I didn't find significant slowdown.
Some slowdown is visible (about 10%) for query
Pavel Stehule writes:
> Test for 3000 elements:
>Original Patch
> Integer55sec 8sec
> Numeric 341sec 8sec
> Quicksort is about 3x faster -- so a benefit of this patch is clear.
Yeah, the patch should pretty much blow the doors off any case
2015-05-01 20:53 GMT+02:00 Pavel Stehule :
>
>
> 2015-05-01 20:11 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > I am looking on this patch, but it cannot be applied now.
>>
>> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
>> > utils/fmgrtab.o:(.rodata+0x2678): undefined referenc
2015-05-01 20:11 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > I am looking on this patch, but it cannot be applied now.
>
> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> > utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> > utils/fmgrtab.o:(.rodata+0x2698)
Andres Freund writes:
> On 2015-05-01 11:11:14 -0700, Tom Lane wrote:
>> What are you trying to apply it to? I see array_append() in
>> src/backend/utils/adt/array_userfuncs.c in HEAD. Also, are
>> you checking the 1.1 version of the patch?
> That's very likely due to the transforms patch, with
On 2015-05-01 11:11:14 -0700, Tom Lane wrote:
> Pavel Stehule writes:
> > I am looking on this patch, but it cannot be applied now.
>
> > lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> > utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> > utils/fmgrtab.o:(.rodata
Pavel Stehule writes:
> I am looking on this patch, but it cannot be applied now.
> lxml2 -lssl -lcrypto -lrt -lcrypt -ldl -lm -o postgres
> utils/fmgrtab.o:(.rodata+0x2678): undefined reference to `array_append'
> utils/fmgrtab.o:(.rodata+0x2698): undefined reference to `array_prepend'
What are
2015-05-01 18:35 GMT+02:00 Tom Lane :
> Andres Freund writes:
> > On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
> >> This is overdue for a rebase; attached. No functional changes, but some
> >> of what was in the original patch has already been merged, and other
> parts
> >> were superseded.
>
>
On 2015-05-01 09:35:08 -0700, Tom Lane wrote:
> Andres Freund writes:
> > What are your plans with this WRT 9.5?
>
> I'd like to get it committed into 9.5. I've been hoping somebody would do
> a performance review.
Ok. I'll try to have a look, but it'll be the second half of next week.
Greetin
Andres Freund writes:
> On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
>> This is overdue for a rebase; attached. No functional changes, but some
>> of what was in the original patch has already been merged, and other parts
>> were superseded.
> What are your plans with this WRT 9.5?
I'd like to
On 2015-03-28 17:24:36 -0400, Tom Lane wrote:
> I wrote:
> > [ expanded-arrays-1.0.patch ]
>
> This is overdue for a rebase; attached. No functional changes, but some
> of what was in the original patch has already been merged, and other parts
> were superseded.
What are your plans with this WRT
On 04/17/2015 03:58 PM, Tom Lane wrote:
Heikki Linnakangas writes:
On 03/28/2015 11:24 PM, Tom Lane wrote:
+ * Macros for iterating through elements of a flat or expanded array.
How about a struct instead?
struct ArrayIter {
Datum datumptr;
bool isnullptr;
char d
Heikki Linnakangas writes:
> On 03/28/2015 11:24 PM, Tom Lane wrote:
>> + * Macros for iterating through elements of a flat or expanded array.
> How about a struct instead?
> struct ArrayIter {
> Datum datumptr;
> bool isnullptr;
> char dataptr;
> bits8 bitmapptr;
>
On 03/28/2015 11:24 PM, Tom Lane wrote:
+ /*
+ * Macros for iterating through elements of a flat or expanded array.
+ * Use "ARRAY_ITER ARRAY_ITER_VARS(name);" to declare the local variables
+ * needed for an iterator (more than one set can be used in the same function,
+ * if they have diff
Attached is an 0.3 version, rebased over today's HEAD changes (applies to
commit 9e3ad1aac52454569393a947c06be0d301749362 or later), and with some
better logic for transferring expanded array values into and out of plpgsql
functions. Using this example:
create or replace function arraysetnum(n in
On Sun, Feb 15, 2015 at 6:41 PM, Tom Lane wrote:
> I'm going to stick this into the commitfest even though it's not really
> close to being committable; I see some other people doing likewise with
> their pet patches ;-). What it could particularly do with some reviewing
> help on is exploring th
Here's an updated version of the patch I sent before. Notable changes:
* I switched over to calling "deserialized" objects "expanded" objects,
and the default representation is now called "flat" or "flattened" instead
of "reserialized". Per suggestion from Robert.
* I got rid of the bit about d
Robert Haas writes:
> On Sat, Feb 14, 2015 at 10:45 AM, Tom Lane wrote:
>> Martijn van Oosterhout writes:
>>> The words that sprung to mind for me were: packed/unpacked.
>> Trouble is that we're already using "packed" with a specific connotation
>> in that same area of the code, namely for shor
On Sat, Feb 14, 2015 at 10:45 AM, Tom Lane wrote:
> Martijn van Oosterhout writes:
>> On Thu, Feb 12, 2015 at 08:52:56AM -0500, Robert Haas wrote:
BTW, I'm not all that thrilled with the "deserialized object" terminology.
I found myself repeatedly tripping up on which form was serialize
Martijn van Oosterhout writes:
> On Thu, Feb 12, 2015 at 08:52:56AM -0500, Robert Haas wrote:
>>> BTW, I'm not all that thrilled with the "deserialized object" terminology.
>>> I found myself repeatedly tripping up on which form was serialized and
>>> which de-. If anyone's got a better naming id
On 2/13/15 2:04 AM, Martijn van Oosterhout wrote:
On Thu, Feb 12, 2015 at 08:52:56AM -0500, Robert Haas wrote:
> >BTW, I'm not all that thrilled with the "deserialized object" terminology.
> >I found myself repeatedly tripping up on which form was serialized and
> >which de-. If anyone's got a
On Thu, Feb 12, 2015 at 08:52:56AM -0500, Robert Haas wrote:
> > BTW, I'm not all that thrilled with the "deserialized object" terminology.
> > I found myself repeatedly tripping up on which form was serialized and
> > which de-. If anyone's got a better naming idea I'm willing to adopt it.
>
> M
On Thu, Feb 12, 2015 at 9:50 AM, Tom Lane wrote:
>> My first thought is that we should form some kind of TOAST-like
>> backronym, like Serialization Avoidance Loading and Access Device
>> (SALAD) or Break-up, Read, Edit, Assemble, and Deposit (BREAD). I
>> don't think there is anything per se wro
Robert Haas writes:
> On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane wrote:
>> BTW, I'm not all that thrilled with the "deserialized object" terminology.
>> I found myself repeatedly tripping up on which form was serialized and
>> which de-. If anyone's got a better naming idea I'm willing to adopt i
On Tue, Feb 10, 2015 at 3:00 PM, Tom Lane wrote:
> I've now taken this idea as far as building the required infrastructure
> and revamping a couple of array operators to use it. There's a lot yet
> to do, but I've done enough to get some preliminary ideas about
> performance (see below).
Very im
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think restricting this feature to varlena types is just fine.
Agreed.
Thanks,
Stephen
signature.asc
Description: Digital signature
Jim Nasby writes:
> On 2/10/15 5:19 PM, Tom Lane wrote:
>> What do you mean by non-variant?
> Ugh, sorry, brainfart. I meant to say non-varlena.
> I can't think of any non-varlena types we'd want this for, but maybe
> someone else can think of a case. If there is a use-case I wouldn't
> handle
On 2/10/15 5:19 PM, Tom Lane wrote:
Jim Nasby writes:
Without having read the patch, I think this is great. I've been wishing
for something like this while working on my variant data type.
Are there any cases where we would want to use this on a non-variant?
Perhaps types where we're paying
Jim Nasby writes:
> Without having read the patch, I think this is great. I've been wishing
> for something like this while working on my variant data type.
> Are there any cases where we would want to use this on a non-variant?
> Perhaps types where we're paying an alignment penalty?
What do
Without having read the patch, I think this is great. I've been wishing
for something like this while working on my variant data type.
Are there any cases where we would want to use this on a non-variant?
Perhaps types where we're paying an alignment penalty?
On 2/10/15 3:00 PM, Stephen Frost
[ this is addressing a tangential point ... ]
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> * Although I said above that everything owned by a deserialized object
>> has to live in a single memory context, I do have ideas about relaxing
>> that. The core idea would be to inve
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I've now taken this idea as far as building the required infrastructure
> and revamping a couple of array operators to use it. There's a lot yet
> to do, but I've done enough to get some preliminary ideas about
> performance (see below).
Nice!
> * A
I've been fooling around with a design to support computation-oriented,
not-necessarily-contiguous-blobs representations of datatypes in memory,
along the lines I mentioned here:
http://www.postgresql.org/message-id/2355.1382710...@sss.pgh.pa.us
In particular this is meant to reduce the overhead f
52 matches
Mail list logo
