2011/1/25 Tom Lane <t...@sss.pgh.pa.us>:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Tue, Jan 25, 2011 at 10:03 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> The arguments that were made against this were about maintenance costs
>>> and code footprint. Claims about performance are not really relevant,
>>> especially when they're entirely unsupported by evidence.
>
>> How much evidence do you need to the effect that detoasting a value
>> that's never used will hurt performance?
>
> I agree that at some microscopic level it will cost something. What's
> not been shown is that there's any significant cost in any real-world
> use pattern. As Pavel said upthread, the main thing here is to get rid
> of cases where there are many many repeated detoastings. Adding an
> occasional detoast that wouldn't have happened before is a good tradeoff
> for that. To convince me that we should contort the code to go further,
> you need to show that that's more than a negligible cost.
I did a few tests:
create table a1(a int);
create table a2(a int)
insert into a1 select array_fill(1, array[100]) from generate_series(1,10000);
insert into a2 select array_fill(1, array[10000]) from generate_series(1,10000);
create or replace function s(int[]) returns int as $$
declare s int = 0; i int;
begin
for i in array_lower($1,1) .. array_upper($1,1)
loop
s := s + $1[i];
end loop;
return s;
end;
$$ language plpgsql immutable;
next I tested queries
1, select sum(s(a)) from a1;
2, select sum(s(a)) from a2;
variant a) my first patch - detoast on first usage with avoiding to
useless detoast checking
variant b) my first patch - detoast on first usage without avoiding to
useless detoast checking
time for 1 - about 300 ms, a is bout 1.5% faster than b
time for 2 - about 30000 ms, a is about 3% faster than b
Regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
