Re: Join optimisation Quandry

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Ceri Storey <cez(at)necrofish(dot)org(dot)uk>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Join optimisation Quandry
Date: 2004-01-17 06:05:54
Message-ID: 20040116220146.N81715@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, 17 Jan 2004, Ceri Storey wrote:

> On Fri, Jan 16, 2004 at 10:17:50AM -0800, Stephan Szabo wrote:
> > As a starting point, we're likely to need the exact query, explain analyze
> > output for the query and version information.
>
> Okay, from top to bottom:
>
> SELECT p1.chan_name, p1.prog_start AS now_start, p1.prog_id, p1.title_text,
> p2.prog_start AS next_start, p2.prog_id, p2.title_text,
> p1.title_wanted, p2.title_wanted, p1.chan_id
> FROM (programme natural join channel NATURAL JOIN title) AS p1
> LEFT OUTER JOIN (programme NATURAL JOIN title) AS p2
> ON p1.prog_next = p2.prog_id
> WHERE p1.prog_start <= timestamp 'now' AND p1.prog_stop > timestamp 'now'
> ORDER BY p1.chan_id ASC
>

Well the plan would seems reasonable to me if there really was only 1 row
coming from the where conditions on p1. As a first step, if you raise the
statistics target (see ALTER TABLE) for prog_start and prog_stop and
re-analyze the table, do you get a better estimate of the rows from that
condition? Secondly, what do you get if you enable_nestloop=off before
explain analyzing the query?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Ceri Storey 2004-01-17 10:40:49 Re: Join optimisation Quandry
Previous Message Mark Kirkwood 2004-01-17 01:51:26 Re: Potential Problem with PostgeSQL performance on SuSE