BUG #7598: Loss of view performance after dump/restore of the view definition - Mailing list pgsql-bugs
| From | vaclav.juza@xitee.com |
|---|---|
| Subject | BUG #7598: Loss of view performance after dump/restore of the view definition |
| Date | |
| Msg-id | E1TMGxP-0007Th-2h@wrigleys.postgresql.org Whole thread Raw |
| Responses |
Re: BUG #7598: Loss of view performance after dump/restore of the view definition
|
| List | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 7598
Logged by: Vaclav Juza
Email address: vaclav.juza@xitee.com
PostgreSQL version: 9.2.1
Operating system: Linux 2.6.18-128.el5 x86_64 (RHEL 5.3)
Description: =
Hi,
when a view (with the below properites) is dump and restored (no matter if
using pg_dump, copied from pg_admin or using pg_views) it's performance is
worse than before. The view was using tables with columns of type "character
varying(xx)" and the dump inserts "::text" casts into the join conditions on
these columns.
In the real case we faced this problem, the performance loss was much higher
on PostgreSQL 9.2.1 (3 seconds vs. 3 minutes) than on 9.1.4 (1.3 seconds vs.
7 seconds) and both variants were slower on 9.2.1 than on 9.1.4. In the test
case below the behaviour is similar on both Postgres version.
The testcase was created in a way that it has similar constructs as the
real-word case.
The testcase is initialized with the following (on our hardware it runs cca
1 minute):
=3D=3D=3D=3D=3D=3D=3D=3D TEST SETUP =3D=3D=3D=3D=3D=3D=3D
set search_path=3Dpublic, pg_catalog;
create table testtable
(
ida character varying (10), idb character varying (10), idc character
varying (10),
lvl numeric, val numeric
);
alter table testtable add constraint pk_testtable primary key (ida, idb,
idc, lvl);
create table testtable2
(
ida character varying (10), idb character varying (10), idc character
varying (10),
idd character varying (10),
lvl numeric, val numeric
);
alter table testtable2 add constraint pk_testtable2 primary key (ida, idb,
idc, idd, lvl);
insert into testtable
select
'a' || a.a, 'bb' || b.b, 'ccc' || c.c,
(37*a.a + 53*b.b + 71*c.c + 101*lvl.lvl) % 512,
( 31*a.a + 17*b.b + 7*c.c + 11*lvl.lvl ) % 16
from
generate_series(1, 5) a, generate_series(1, 50) b, generate_series(1, 500)
c,
generate_series(1, 9) lvl;
insert into testtable2
select
'a' || a.a, 'bb' || b.b, 'ccc' || 5*c.c, 'dddd' || d.d,
(37*a.a + 53*b.b + 71*5*c.c + 101*3*lvl.lvl) % 512,
(31*a.a + 17*b.b + 7*5*c.c + 11*3*lvl.lvl) % 3
from generate_series(1, 5) a, generate_series(1, 50) b, generate_series(1,
100) c,
generate_series(1, 10) d,
generate_series(1, 3) lvl;
create or replace view testview as
select t1.ida, t1.idb, t1.idc, t1.lvl, t1.val
from testtable t1
join testtable2 t6
on t6.ida=3Dt1.ida and t6.idb=3Dt1.idb and t6.idc=3Dt1.idc and
t6.idd=3D'dddd1'
and t6.lvl=3D
(
SELECT max(t7.lvl)
from testtable2 t7
where t7.ida=3Dt6.ida and t7.idb=3Dt6.idb and t7.idc=3Dt6.idc
and t7.idd=3Dt6.idd and t7.lvl<300
)
where t1.lvl=3D
(
SELECT max(t2.lvl)
from testtable t2
where t2.ida=3Dt1.ida and t2.idb=3Dt1.idb and t2.idc=3Dt1.idc and t2.lv=
l<300
)
and (t1.ida, t1.idb, t1.idc) in
( select t3.ida, t3.idb, t3.idc
from testtable2 t3
join testtable t5
on t5.ida=3Dt3.ida and t5.idb=3Dt3.idb and t5.idc=3Dt3.idc
where t3.lvl=3D
(
SELECT min(t4.lvl)
from testtable2 t4
where t4.ida=3Dt3.ida and t4.idb=3Dt3.idb and t4.idc=3Dt3.idc and
t4.idd=3Dt3.idd
and t4.lvl<300
)
and t3.idd=3D'dddd8' and t3.val=3D0
)
;
=3D=3D=3D=3D END TEST SETUP =3D=3D=3D=3D=3D=3D=3D
The following query:
select * from testview where ida=3D'a4';
has the following performance on our hardware:
-- pg 9.2.1: time~=3D1.2s, cost=3D119222.86..123174.62
-- pg 9.1.4: time~=3D1.1s, cost=3D105848.75..112083.82
After recreating the view from dump or simplier from pg_views:
DO language plpgsql $$
declare
begin
execute ''::text ||
(
select 'CREATE OR REPLACE VIEW ' || viewname || ' AS ' ||definition
from pg_views where schemaname=3D'public' and viewname=3D'testview'
);
end;
$$
the same query
select * from testview where ida=3D'a4';
on the same hardware has the following performance:
-- pg 9.2.1: time~=3D2.5s, cost=3D578843.62..587364.78
-- pg 9.1.4: time~=3D2.5s, cost=3D513879.12..521655.37
Expected:
The performance and execution plan of the query should be the same when the
view is dumped and restored.
Regards,
Vaclav Juza
pgsql-bugs by date: