Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C12D36331E2 for ; Mon, 4 Jan 2010 22:09:13 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 23743-03 for ; Tue, 5 Jan 2010 02:09:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mail.postgresql.org (Postfix) with ESMTP id EF97763237E for ; Mon, 4 Jan 2010 22:09:02 -0400 (AST) Received: by fxm27 with SMTP id 27so1333137fxm.3 for ; Mon, 04 Jan 2010 18:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XSMbWVeC3cm1bSlWQ6z8XbPPPF3E60rAjUT5J+IKERw=; b=pw3TemEAiQePgrI84B240blxZkvT6SCWsM7DaCxLFSSyuVSDNWu6jaj2rWL1TXGt6K eCiIiLS6ta68H9moqgiVJb1H7zU04EUiSlJ7fAszXL3u7pEnEMc5DY16dgIRABEo4L2/ s1h96JJLF/y9kZ/dmHnjnfPyUttoYtevh9Wks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nS7OGBOEUKAPfFnTnCzFrHvejwG56TZeFXP+8+RwtFS/9r+STIjE8Tf2a/c0YGa5f/ tFpcOIy3f+0TL/o8AdCAEyUSzggHd5QAzsinlR/fZQZnGwtBBeIhZzkUexzr8VfET2K6 oC5tbFJ1sBInFvscYAohwiRRFJFHVCyyawB0Y= MIME-Version: 1.0 Received: by 10.239.137.69 with SMTP id k5mr1411057hbk.97.1262657340837; Mon, 04 Jan 2010 18:09:00 -0800 (PST) In-Reply-To: References: <000f01ca8d87$88e71f30$9ab55d90$@hu> <603c8f071001041359u58159c49k10587c7c46424672@mail.gmail.com> Date: Mon, 4 Jan 2010 21:09:00 -0500 Message-ID: <603c8f071001041809g3b564310yb5cfb31ae7bf23b6@mail.gmail.com> Subject: Re: forced sequential scan when condition has current_user From: Robert Haas To: Erik Jones Cc: =?ISO-8859-1?Q?Keresztury_Bal=E1zs?= , pgsql-performance@postgresql.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.003 tagged_above=-10 required=5 tests=BAYES_40=-0.185, FH_DATE_PAST_20XX=3.188 X-Spam-Level: *** X-Archive-Number: 201001/34 X-Sequence-Number: 36914 2010/1/4 Erik Jones : > On Jan 4, 2010, at 1:59 PM, Robert Haas wrote: >> The thing is, PostgreSQL doesn't know at planning time what the value of >> current_user() will be, so the plan can't depend on that; the planner >> just takes its best shot. > > current_user() is a stable function and the manual is explicit that the result of stable function can be used in an index scan: That's true, but what I said is also true. It CAN be used in an index scan, and on a sufficiently large table it WILL be used in an index scan (I tried it). But the planner doesn't automatically use an index just because there is one; it tries to gauge whether that's the right strategy. Unfortunately, in cases where it is comparing to a function rather than a constant, its estimates are not always terribly accurate. One thing I notice is that the OP has not included any information on how fast the seqscan or index-scan actually is. If the seqscan is slower than the index-scan, then the OP might want to consider adjusting the page cost parameters - EXPLAIN ANALYZE output for both plans (perhaps obtained by temporarily setting enable_seqscan to false) would be helpful in understanding what is happening. ...Robert