From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | "dbyzaa(at)163(dot)com" <dbyzaa(at)163(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] temporary table vs array performance |
Date: | 2016-09-26 16:16:31 |
Message-ID: | CAFj8pRBmxtxGDKG3pAgieS6UD_aaT3PysGMBqA=CmDwd1Hf2hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers pgsql-performance |
2016-09-26 17:39 GMT+02:00 dbyzaa(at)163(dot)com <dbyzaa(at)163(dot)com>:
> test:
> create type h3 as (id int,name char(10));
>
> CREATE or replace FUNCTION proc17()
> RETURNS SETOF h3 AS $$
> DECLARE
> v_rec h3;
> BEGIN
> create temp table abc(id int,name varchar) on commit drop;
> insert into abc select 1,'lw';
> insert into abc select 2,'lw2';
> for v_rec in
> select * from abc loop
> return next v_rec;
> end loop;
> END;
> $$
> LANGUAGE plpgsql;
>
>
> CREATE or replace FUNCTION proc16()
> RETURNS SETOF h3 AS $$
> DECLARE
> id_array int[];
> name_arr varchar[];
> v_rec h3;
> BEGIN
> id_array =array[1,2];
> name_arr=array['lw','lw2'];
> for v_rec in
> select unnest(id_array) ,unnest(name_arr) loop
> return next v_rec;
> end loop;
> END;
> $$
> LANGUAGE plpgsql;
> postgres=# select * from proc17();
> id | name
> ----+------------
> 1 | lw
> 2 | lw2
> (2 rows)
>
> Time: 68.372 ms
> postgres=# select * from proc16();
> id | name
> ----+------------
> 1 | lw
> 2 | lw2
> (2 rows)
>
> Time: 1.357 ms
>
> temp talbe result:
> [postgres(at)pg95 test_sql]$ pgbench -M prepared -n -r -c
> 2 -j 2 -T 10 -f temporary_test_1.sql
> transaction type: Custom query
> scaling factor: 1
> query mode: prepared
> number of clients: 2
> number of threads: 2
> duration: 10 s
> number of transactions actually processed: 5173
> latency average: 3.866 ms
> tps = 517.229191 (including connections establishing)
> tps = 517.367956 (excluding connections establishing)
> statement latencies in milliseconds:
> 3.863798 select * from proc17();
>
> array result:
> [postgres(at)pg95 test_sql]$ pgbench -M prepared -n -r -c
> 2 -j 2 -T 10 -f arrary_test_1.sql
> transaction type: Custom query
> scaling factor: 1
> query mode: prepared
> number of clients: 2
> number of threads: 2
> duration: 10 s
> number of transactions actually processed: 149381
> latency average: 0.134 ms
> tps = 14936.875176 (including connections establishing)
> tps = 14940.234960 (excluding connections establishing)
> statement latencies in milliseconds:
> 0.132983 select * from proc16();
>
> Array is not convenient to use in function, whether
> there are other methods can be replaced temp table in function
>
>
Temporary tables are pretty expensive - from more reasons, and horrible
when you use fresh table for two rows only. More if you recreate it every
transaction.
More often pattern is create first and delete repeatedly. Better don't use
temp tables when it is necessary. It is one reason why PostgreSQL supports
a arrays. Partially - PostgreSQL arrays are analogy to T-SQL memory tables.
Regards
Pavel
>
> ------------------------------
> dbyzaa(at)163(dot)com
>
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-09-26 16:23:52 | Re: [HACKERS] temporary table vs array performance |
Previous Message | David G. Johnston | 2016-09-26 15:49:42 | Re: [HACKERS] temporary table vs array performance |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-09-26 16:19:23 | Re: proposal: psql \setfileref |
Previous Message | Enrique Meneses | 2016-09-26 16:04:05 | Re: Allowing GIN array_ops to work on anyarray |
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-09-26 16:23:52 | Re: [HACKERS] temporary table vs array performance |
Previous Message | Knels, Udo | 2016-09-26 15:59:58 | Re: Problem with performance using query with unnest after migrating from V9.1 to V9.2 and higher |