Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: <mallah@trade-india.com>
Subject: Re: Why is seq search preferred here by planner?
Date: Wed, 23 Apr 2003 12:53:52 -0700
User-Agent: KMail/1.4.3
Cc: <pgsql-sql@postgresql.org>
References: <1220.219.65.235.51.1051114881.squirrel@mail.trade-india.com>
	<200304231120.56699.josh@agliodbs.com>
	<1331.219.65.233.8.1051123905.squirrel@mail.trade-india.com>
In-Reply-To: <1331.219.65.233.8.1051123905.squirrel@mail.trade-india.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200304231253.52051.josh@agliodbs.com>

Mallah,

> > The reason that the planner is using a seq scan on=20
personal_account_details is  the same as the
> > reason for using  a seq scan on email_bank; the number of  rows which=
=20
match the condition,
> > about 150,000.   With that many qualifying  rows, a seq scan is faster.
>=20
>=20
> But there are two tables here , email_bank and personal_account_details
> in personal account details only one row is supposed to match a given use=
rid
> as userid is the PKEY , why seq_scan there ? or am i getting the explain=
=20
wrong ?

It doesn't matter whether it's a primary key or not.  If your query or=20
subquery condition returns a large number/proportion of rows, a seq scan is=
=20
going to be faster than an index scan.=20=20

As far as userid being a key, this affects the planner's *join method*, *no=
t*=20
how the database gets the rows.=20=20=20


--=20
-Josh Berkus
 Aglio Database Solutions
 San Francisco