Re: performance tuning in large function / transaction - Mailing list pgsql-sql
From | MindTerm |
---|---|
Subject | Re: performance tuning in large function / transaction |
Date | |
Msg-id | 20011218073907.397.qmail@web20209.mail.yahoo.com Whole thread Raw |
In response to | Re: performance tuning in large function / transaction (Stephan Szabo <sszabo@megazone23.bigpanda.com>) |
Responses |
Re: performance tuning in large function / transaction
|
List | 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@megazone23.bigpanda.com> wrote: > > --- Stephan Szabo <sszabo@megazone23.bigpanda.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@postgresql.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