Message-ID: <1386.219.65.253.85.1051128809.squirrel@mail.trade-india.com>
Date: Thu, 24 Apr 2003 01:43:29 +0530 (IST)
Subject: Re: Why is seq search preferred here by planner?
From: <mallah@trade-india.com>
To: <josh@agliodbs.com>
In-Reply-To: <200304231253.52051.josh@agliodbs.com>
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>
	<200304231253.52051.josh@agliodbs.com>
Importance: Normal
Cc: <mallah@trade-india.com>, <pgsql-sql@postgresql.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

> Mallah,
>
>> > The reason that the planner is using a seq scan on
> personal_account_details is  the same as the
>> > reason for using  a seq scan on email_bank; the number of  rows which
> match the condition,
>> > about 150,000.   With that many qualifying  rows, a seq scan is faster.
>>
>>
>> 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 userid as userid is th=
e PKEY , why seq_scan
>> there ? or am i getting the explain
> wrong ?
>
> It doesn't matter whether it's a primary key or not.  If your query or  s=
ubquery condition
> returns a large number/proportion of rows, a seq scan is  going to be fas=
ter than an index
> scan.
>
> As far as userid being a key, this affects the planner's *join method*, *=
not*  how the database
> gets the rows.

Got it , you mean to say userid being pkey  is affecting the method of
implicit join being made by the update  stmt.

thanks once again.

Regds
mallah.


>
>
> --
> -Josh Berkus
> Aglio Database Solutions
> San Francisco


-----------------------------------------
Get your free web based email at trade-india.com.
   "India's Leading B2B eMarketplace.!"
http://www.trade-india.com/