From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql |
Date: | 2011-03-11 06:09:37 |
Message-ID: | AANLkTik-mS5pCLA0BH9wypORwOH698=AKwFNtYEb7iE2@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2011/3/11 Bruce Momjian <bruce(at)momjian(dot)us>:
>
> What happened with this patch? Alvaro saw a 25x speedup.
There is not conformance about form in this patch. But there are a
FOREACH statement - so if somebody uses this statement, then he will
not have a problems with performance.
Regards
Pavel
>
> ---------------------------------------------------------------------------
>
> Pavel Stehule wrote:
>> Hello
>>
>> this patch remove a multiple detoasting of varlena values in plpgsql.
>>
>> It is usable mainly for iteration over longer array directly loaded
>> from relation.
>>
>> It's doesn't have a impact on semantic or behave - it's just eliminate
>> some performance trap.
>>
>> sample: table 10000 rows one column with array with 1000 string fields:
>>
>> patched pl time: 6 sec
>> unpatched pl time: 170 sec
>>
>> This doesn't change my opinion on FOR-IN-ARRAY cycle (is still
>> important for readability) - just remove one critical performance
>> issue
>>
>> Regards
>>
>> Pavel Stehule
>
> [ Attachment, skipping... ]
>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>
> --
> Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-03-11 07:45:40 | Re: On-the-fly index tuple deletion vs. hot_standby |
Previous Message | Fujii Masao | 2011-03-11 04:21:51 | Re: Hot Standby btree delete records and vacuum_defer_cleanup_age |