Re: Why is seq search preferred here by planner?
От | |
---|---|
Тема | Re: Why is seq search preferred here by planner? |
Дата | |
Msg-id | 1386.219.65.253.85.1051128809.squirrel@mail.trade-india.com обсуждение исходный текст |
Ответ на | Re: Why is seq search preferred here by planner? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Why is seq search preferred here by planner?
|
Список | 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/
В списке pgsql-sql по дате отправления: