Re: query optimization scenarios 17,701 times faster!!!
От | Stephan Szabo |
---|---|
Тема | Re: query optimization scenarios 17,701 times faster!!! |
Дата | |
Msg-id | 20030424144318.V5349-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: query optimization scenarios 17,701 times faster!!! ("Robert Dyas" <rdyas@adelphia.net>) |
Ответы |
Re: query optimization scenarios 17,701 times faster!!!
|
Список | pgsql-hackers |
On Thu, 24 Apr 2003, Robert Dyas wrote: > Actually, what I'm suggesting first is much more straight forward. Each > operation must take place on a row set. When you've got a bunch of tables > that are joined together, and columns with unique indexes are specified in > the where clause to be equal to some simple value (regalrdless of which > table), then before you do any other processing, make sure you only process > on that single row! Don't join a million rows together only to throw them > all out but one!! Which it appears is exactly what 7.3.1 was doing. It It doesn't look that way to me. It looks to me from the explain output that it was doing an index scan getting the one row from the table with the condition and then joining that with each successive table (possibly getting additional rows from those), then doing a sort and unique for the distinct.
В списке pgsql-hackers по дате отправления: