Re: query optimization scenarios 17,701 times faster!!!

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Robert Dyas <rdyas(at)adelphia(dot)net>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: query optimization scenarios 17,701 times faster!!!
Date: 2003-04-24 21:45:49
Message-ID: 20030424144318.V5349-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2003-04-24 21:52:17 Re: query optimization scenarios 17,701 times faster!!!
Previous Message scott.marlowe 2003-04-24 21:18:42 Re: query optimization scenarios 17,701 times faster!!!