Re: Join optimisation Quandry

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ceri Storey <cez-misc(dot)pgsql-perf(at)necrofish(dot)org(dot)uk>
Cc: Ceri Storey <cez(at)necrofish(dot)org(dot)uk>, Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Join optimisation Quandry
Date: 2004-01-19 02:21:00
Message-ID: 18213.1074478860@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ceri Storey <cez-misc(dot)pgsql-perf(at)necrofish(dot)org(dot)uk> 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 look like you've ever vacuumed or analyzed "tid" --- those
are the default cost and rows estimates. Although I'm unsure whether
the plan would change much if you had.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Neil Conway 2004-01-19 23:58:44 Re: COUNT & Pagination
Previous Message John Siracusa 2004-01-17 21:33:56 Re: Idle postmaster taking up a lot of CPU