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
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 |