From: | <mallah(at)trade-india(dot)com> |
---|---|
To: | <josh(at)agliodbs(dot)com> |
Cc: | <mallah(at)trade-india(dot)com>, <pgsql-sql(at)postgresql(dot)org> |
Subject: | Re: Why is seq search preferred here by planner? |
Date: | 2003-04-23 20:13:29 |
Message-ID: | 1386.219.65.253.85.1051128809.squirrel@mail.trade-india.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> 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 the 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 subquery condition
> returns a large number/proportion of rows, a seq scan is going to be faster 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-04-23 20:21:06 | Re: Why is seq search preferred here by planner? |
Previous Message | Josh Berkus | 2003-04-23 19:53:52 | Re: Why is seq search preferred here by planner? |