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