Re: performance tuning in large function / transaction

From: MindTerm <mindterm(at)yahoo(dot)com>
To: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: performance tuning in large function / transaction
Date: 2001-12-18 07:39:06
Message-ID: 20011218073907.397.qmail@web20209.mail.yahoo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

Dear stephan,

I found that the long execution time was due to
following statement which will execute many times in a
loop:

select count(*)
from ACL, APPLICATION app
where ACL_APP = app.app_id
and APP_INSTALLED = 'Y'
and ACL_LEVEL > 0
and ACL_GALLERY_ID = 1
and app.APP_GALLERY_ID = 1
and substr(app.app_order,1, 6 ) = '021101'
and app.app_order <> '021101'
and ACL_GRP in
(select u.ug_id
from user_group u, user_group_master
ug
where u.ug_user_id = 5170
and ug.ug_id = u.ug_id
and (ug.deleted = 'N' or ug.deleted
IS NULL)
and u.gallery_id = 1
and ug.gallery_id = 1 );

I had explain it and got the result :
Aggregate (cost=4836.61..4836.61 rows=1 width=24)
-> Nested Loop (cost=0.00..4836.61 rows=2
width=24)
-> Index Scan using
application_app_gallery_id on application app
(cost=0.00..3.05 rows=1 width=12)
-> Index Scan using acl_acl_gallery_id on acl
(cost=0.00..4830.80 rows=220 width=12)
SubPlan
-> Materialize (cost=6.10..6.10
rows=1 width=24)
-> Nested Loop
(cost=0.00..6.10 rows=1 width=24)
-> Index Scan using
user_group_ug_user_id on user_group u
(cost=0.00..2.02 rows=1 width=12)
-> Index Scan using
user_group_master_gallery_id on user_group_master ug
(cost=0.00..4.07 rows=1 width=12)

after rewrote it to :

select count(*)
from ACL a, APPLICATION app
where ACL_APP = app.app_id
and APP_INSTALLED = 'Y'
and ACL_LEVEL > 0
and ACL_GALLERY_ID = 1
and app.APP_GALLERY_ID = 1
and substr(app.app_order,1, 6 ) = '021101'
and app.app_order <> '021101'
and exists
(select u.ug_id
from user_group u, user_group_master
ug
where a.ACL_GRP = u.ug_id
and u.ug_user_id = 5170
and ug.ug_id = u.ug_id
and (ug.deleted = 'N' or ug.deleted
IS NULL)
and u.gallery_id = 1
and ug.gallery_id = 1 );

the explain was :
Aggregate (cost=4836.69..4836.69 rows=1 width=24)
-> Nested Loop (cost=0.00..4836.69 rows=2
width=24)
-> Index Scan using
application_app_gallery_id on application app
(cost=0.00..3.05 rows=1 width=12)
-> Index Scan using acl_acl_gallery_id on acl
a (cost=0.00..4830.89 rows=220 width=12)
SubPlan
-> Nested Loop (cost=0.00..6.10
rows=1 width=24)
-> Index Scan using
user_group_ug_id on user_group u (cost=0.00..2.02
rows=1 width=12)
-> Index Scan using
user_group_master_gallery_id on user_group_master ug
(cost=0.00..4.07 rows=1 width=12)

the performance seems no improvement.

the table ACL contains 106057 rows and index on
acl_gallery_id, acl_grp and acl_level .

the table APPLICATION contains 220 rows and index on
app_gallery_id and app_order .

-- Table: acl
CREATE TABLE "acl" (
"acl_id" numeric(10, 0) DEFAULT 0 NOT NULL,
"acl_app" numeric(10, 0),
"acl_grp" numeric(10, 0),
"acl_level" numeric(3, 0),
"acl_gallery_id" numeric(11, 0),
CONSTRAINT "acl_acl_app_key" UNIQUE ("acl_app",
"acl_grp"),
CONSTRAINT "acl_pkey" PRIMARY KEY ("acl_id"),
CONSTRAINT "acl_fk9992931283980" FOREIGN KEY
(acl_app) REFERENCES "application" (app_id) ON DELETE
NO ACTION ON UPDATE NO ACTION NOT DEFERRABLE INITIALLY
IMMEDIATE,
CONSTRAINT "acl_ug" FOREIGN KEY (acl_grp) REFERENCES
"user_group_master" (ug_id) ON DELETE NO ACTION ON
UPDATE NO ACTION NOT DEFERRABLE INITIALLY IMMEDIATE
);

-- Table: application
CREATE TABLE "application" (
"app_id" numeric(11, 0) NOT NULL,
"app_en_name" varchar(100) NOT NULL,
"app_tc_name" varchar(100),
"app_sc_name" varchar(100),
"app_menu" varchar(1),
"app_installed" varchar(1),
"app_order" varchar(50),
"app_alt" varchar(50),
"app_gif" varchar(100),
"app_link" varchar(100),
"app_initial" varchar(1),
"app_gallery_id" numeric(11, 0),
"app_terminator" varchar(1),
"app_en_length" numeric(4, 0),
"app_tc_length" numeric(4, 0),
"app_sc_length" numeric(4, 0),
"app_ext" varchar(1),
"app_type" varchar(30),
CONSTRAINT "application_pkey" PRIMARY KEY ("app_id")
);

M.T.

--- Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
wrote:
> > --- Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
> > wrote:
> > >
> > > On Fri, 14 Dec 2001, MindTerm wrote:
> > >
> > > > Hi all,
> > > >
> > > > table :
> > > > application : 220 rows ;
> > > > usermenu : 6055 rows ;
> > >
> > > Well, I'd need the other tables involved in the
> > > function
> > > too, but to start with, try rewriting the
> queries in
> > > the
> > > function to use EXISTS rather than IN (see the
> faq),
> > > or
> > > bring them into a normal join with the other
> tables
> > > where
> > > possible.
>
> As a note, does rewriting the queries in the
> function
> to use exists rather than in help any?
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the
> unregister command
> (send "unregister YourEmailAddressHere" to
majordomo(at)postgresql(dot)org)

__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

In response to

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Stephan Szabo 2001-12-18 07:50:15 Re: performance tuning in large function / transaction
Previous Message Stephan Szabo 2001-12-18 06:57:50 Re: Execution time problem