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
Ответ на
Список
Дерево обсуждения
query optimization scenarios 17,701 times faster!!! "Robert Dyas" <rdyas@adelphia.net>
Re: query optimization scenarios 17,701 times faster!!! Tom Lane <tgl@sss.pgh.pa.us>
Re: query optimization scenarios 17,701 times faster!!! "Robert Dyas" <rdyas@adelphia.net>
Re: query optimization scenarios 17,701 times faster!!! Kurt Roeckx <Q@ping.be>
Re: query optimization scenarios 17,701 times faster!!! "Robert Dyas" <rdyas@adelphia.net>
Re: query optimization scenarios 17,701 times faster!!! Stephan Szabo <sszabo@megazone23.bigpanda.com>
Re: query optimization scenarios 17,701 times faster!!! Tom Lane <tgl@sss.pgh.pa.us>
Re: query optimization scenarios 17,701 times faster!!! Dennis Björklund <db@zigo.dhs.org>

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 по дате отправления
От: scott.marlowe
Дата:
От: Stephan Szabo
Дата:
FAQ