From: | pg noob <pgnube(at)gmail(dot)com> |
---|---|
To: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | query plan estimate |
Date: | 2013-03-25 18:16:51 |
Message-ID: | CAPNY-2UhG9QEdvy84bZRx3m0SD3HoCN5jMZAP1yw9jDY_hMpww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi all,
I'm looking at this query plan, an excerpt of which is shown here, and I am
just wondering how the estimated cost for the Nested Loop is calculated?
-> Nested Loop (*cost=0.00..2888.16* rows=240 width=16) (actual
time=0.034..2.180 rows=91 loops=1)
Output: public.mg.lctime, public.mg.gfid
-> Index Scan using _
ba6cf7271af37e26c0e09e3225369f1b on version (*cost=0.00..958.13* rows=240
width=8) (actual time=0.013..0.318 rows=91 loops=1)
Output: version.id, version.gfid, version.tid, version.seq,
version.txsid, version.objectid
-> Index Scan using mgfid__uniq on mg (*cost=0.00..8.03* rows=1
width=16) (actual time=0.005..0.008 rows=1 loops=91)
Output: public.mg.id, public.mg.gfid, public.mg.ftype,
public.mg.lctime
Index Cond: (public.mg.gfid = version.gfid)
Filter: (public.mg.lctime < 1363076849)
What I expected is that it would be the sum of the output cost of the two
index scans?
I have no clue how it came up with 2,888.
Thank you.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2013-03-25 18:18:28 | Re: Performance of query |
Previous Message | Colin Currie | 2013-03-25 09:57:34 | 9.2.3 upgrade reduced pgbench performance by 60% |