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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Amit kapila
Date:
Subject: Re: BUG #7534: walreceiver takes long time to detect n/w breakdown
Next
From: ashu
Date:
Subject: Re: BUG #6451: problem while installing gridsql