Re: [PERFORM] Join optimisation Quandry

2004-01-18 Thread Tom Lane
Ceri Storey <[EMAIL PROTECTED]> writes: > Although, as I've just found, another bottleneck is the title table. > PostgreSQL seems to inst on doing a Seq Scan on the entire table. >-> Seq Scan on tid (cost=0.00..20.00 rows=1000 width=8) (actual > time=0.028..10.457 rows=17 loops=1) It does

Re: [PERFORM] Join optimisation Quandry

2004-01-18 Thread Ceri Storey
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,

Re: [PERFORM] Join optimisation Quandry

2004-01-18 Thread Ceri Storey
On Fri, Jan 16, 2004 at 10:05:54PM -0800, Stephan Szabo wrote: > 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

Re: [PERFORM] Join optimisation Quandry

2004-01-18 Thread Ceri Storey
On Sat, Jan 17, 2004 at 01:03:34AM +, Ceri Storey wrote: > 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 (pr