on flatomfilesysentry_pkey (cost=0.00..2.00 rows=4950 width=0) (actual time=0.014..0.014 rows=1 loops=56) Index Cond: (flatomfilesysentry.objectid = "outer".dstobj) Total runtime: 2.258 ms(14 rows)H Hale <[EMAIL PROTECTED]> wrote: Not sure if this helps solve the problem
Scan on flatomfilesysentry_pkey (cost=0.00..2.00 rows=364 width=0) (actual time=0.009..0.009 rows=1 loops=729) Index Cond: (flatomfilesysentry.objectid = "outer".dstobj) Total runtime: 25.101 ms (14 rows) Time: 26.878 ms H Hale <[EMAIL PROTECTED]> wrote: Tom, It
Lane <[EMAIL PROTECTED]> wrote: H Hale writes:> -> Bitmap Heap Scan on flatomfilesysentry (cost=2.00..274.38 rows=3238 width=30) (actual time=0.011..0.013 rows=1 loops=6473)> Recheck Cond: (flatomfilesysentry.objectid = "outer".dstobj)> -> Bitmap Index Scan
Look at that second seq-scan (on flatommemberrelation) - it's looping 5844 times (once for each row in flatmfilesysentry). I'd expect PG to materialise the seq-scan once and then join (unless I'm missing something, the subselect just involves the one test against a constant).I'm guessing something
I am testing a query what that has a sub-select. The query performance is very very poor as shown below due to the use of sequencial scans. The actual row count of both tables is also shown. It appears the row count shown by explain analyze does not match the actual count. Columns dstobj, srcobj &
