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 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 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 doesn't