Re: [EXPLAIN] Nested loops - Mailing list pgsql-general

From Reg Me Please
Subject Re: [EXPLAIN] Nested loops
Date
Msg-id 200901092027.26190.regmeplease@gmail.com
Whole thread Raw
In response to Re: [EXPLAIN] Nested loops  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
On Friday 09 January 2009 20:00:57 Tom Lane wrote:
> Reg Me Please <regmeplease@gmail.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

pgsql-general by date:

Previous
From: Reg Me Please
Date:
Subject: Re: [EXPLAIN] Nested loops
Next
From: Thomas Pundt
Date:
Subject: Re: [EXPLAIN] Nested loops