Re: [EXPLAIN] Nested loops

From: Reg Me Please <regmeplease(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org, "Victor Nawothnig" <victor(dot)nawothnig(at)gmail(dot)com>
Subject: Re: [EXPLAIN] Nested loops
Date: 2009-01-09 19:27:25
Message-ID: 200901092027.26190.regmeplease@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Friday 09 January 2009 20:00:57 Tom Lane wrote:
> Reg Me Please <regmeplease(at)gmail(dot)com> writes:
> > Aggregate (cost=227.59..227.61 rows=1 width=8)
> > -> Nested Loop (cost=0.00..227.34 rows=49 width=8)
> > -> Seq Scan on T2 (cost=0.00..1.07 rows=6 width=4)
> > Filter: (fld1 = 'VEND'::text)
> > -> Index Scan using i_T1_partial on T1 (cost=0.00..37.61
> > rows=8 width=8)
> > Index Cond: ((T1.prod_id = 42) AND (T1.fk1 = T2.fk1))
>
> If those rowcount estimates are accurate, then this is a perfectly good
> plan; in fact probably the best you could hope for.
>
> regards, tom lane

Rowcounts seems to be quite accurate as the tables get "VACUUM FULL ANALYZE"d
regularly.
This query plan comes from index optimization.
It is the cost estimate for the nested loop that scares me a little.

As of now only file system caching seems to help the timing (by a factor 10)
but this in turn is a transitory effect as I have little control over FS
cache.

--
Fahrbahn ist ein graues Band
weisse Streifen, grüner Rand

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Smith 2009-01-09 20:58:14 Re: Improving compressibility of WAL files
Previous Message Reg Me Please 2009-01-09 19:27:10 Re: [EXPLAIN] Nested loops