forced sequential scan when condition has current_user

From: Keresztury Balázs <balazs(at)gaslightmusic(dot)hu>
To: <pgsql-performance(at)postgresql(dot)org>
Subject: forced sequential scan when condition has current_user
Date: 2010-01-04 21:47:37
Message-ID: 000f01ca8d87$88e71f30$9ab55d90$@hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

hi,

just a small question: is it normal that PostgreSQL 8.4.1 always uses
sequential scanning on any table when there is a condition having the
constant "current_user"? Of course there is a btree index set on that table,
but the DBMS just doesn't want to utilize it. When I replace current_user to
any string, the planner uses the index normally.

I can demonstrate it with the following simple query:

SELECT psz.kotesszam FROM projekt.projektszervezet psz WHERE
psz.felhasznalo_id = current_user;

Explain analyze:

"Seq Scan on projektszervezet psz (cost=0.00..255.07 rows=42 width=9)"
" Filter: ((felhasznalo_id)::name = "current_user"())"

Metadata:

CREATE TABLE "projekt"."projektszervezet" (
CONSTRAINT "projektszervezet_pkey" PRIMARY KEY("kotesszam",
"felhasznalo_id"),
CONSTRAINT "projektszervezet_fk_felhasznalo" FOREIGN KEY
("felhasznalo_id")
REFERENCES "felhasznalo"."felhasznalo"("felhasznalo_id")
ON DELETE RESTRICT
ON UPDATE RESTRICT
NOT DEFERRABLE,
CONSTRAINT "projektszervezet_fk_projekt" FOREIGN KEY ("kotesszam")
REFERENCES "projekt"."projekt"("kotesszam")
ON DELETE CASCADE
ON UPDATE CASCADE
NOT DEFERRABLE,
CONSTRAINT "projektszervezet_fk_szerep" FOREIGN KEY ("szerep_id")
REFERENCES "felhasznalo"."szerep"("szerep_id")
ON DELETE RESTRICT
ON UPDATE RESTRICT
NOT DEFERRABLE
) INHERITS ("projekt"."projektszervezet_sablon")
WITH OIDS;

CREATE INDEX "projektszervezet_idx_felhasznalo_id" ON
"projekt"."projektszervezet"
USING btree ("felhasznalo_id");

CREATE INDEX "projektszervezet_idx_kotesszam" ON
"projekt"."projektszervezet"
USING btree ("kotesszam");

CREATE TRIGGER "projektszervezet_archivalas" BEFORE UPDATE OR DELETE ON
"projekt"."projektszervezet" FOR EACH ROW EXECUTE PROCEDURE
"public"."projektszervezet_archivalas_trigger"();

CREATE TRIGGER "projektszervezet_idopecset" BEFORE UPDATE ON
"projekt"."projektszervezet" FOR EACH ROW EXECUTE PROCEDURE
"public"."idopecset_trigger"();

CREATE TRIGGER "projektszervezet_naplozas" BEFORE INSERT OR UPDATE OR DELETE
ON "projekt"."projektszervezet" FOR EACH ROW EXECUTE PROCEDURE
"public"."projektszervezet_naplozas_trigger"();

Inherited table:

CREATE TABLE "projekt"."projektszervezet_sablon" (
"kotesszam" VARCHAR(10) NOT NULL,
"felhasznalo_id" VARCHAR NOT NULL,
"szerep_id" VARCHAR(3),
"felvivo" VARCHAR DEFAULT "current_user"() NOT NULL,
"felvitel_idopont" TIMESTAMP WITHOUT TIME ZONE DEFAULT now() NOT NULL,
"modosito" VARCHAR,
"modositas_idopont" TIMESTAMP WITHOUT TIME ZONE,
"elso_felvivo" VARCHAR DEFAULT "current_user"() NOT NULL,
"elso_felvitel_idopont" TIMESTAMP(0) WITHOUT TIME ZONE DEFAULT now() NOT
NULL
) WITH OIDS;

CREATE TRIGGER "projektszervezet_idopecset" BEFORE UPDATE ON
"projekt"."projektszervezet_sablon" FOR EACH ROW EXECUTE PROCEDURE
"public"."idopecset_trigger"();

Thanks!
Balazs

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2010-01-04 21:53:18 Re: query looping?
Previous Message Steve Crawford 2010-01-04 21:43:02 Re: DB is slow until DB is reloaded