Index Scan using ix_B on B (cost=0.04..3.06 rows=1 width=329) (actual time=93.824..93.826 rows=1 loops=1)
Index Cond: (id = $0)
InitPlan
-> Limit (cost=0.00..0.04 rows=1 width=4) (actual time=15.128..15.129 rows=1 loops=1)
-> Seq Scan on A (cost=0.00..47569.70 rows=1135570 width=4) (actual time=15.121..15.121 rows=1 loops=1)
Total runtime: 94.109 ms
94 ms for an index scan ? this look really slow...
was the index in the RAM cache ? does it fit ? is it faster the second time ? If it's still that slow, something somewhere is severely screwed.
B has 150K rows you say, so everything about B should fit in RAM, and you should get 0.2 ms for an index scan, not 90 ms !
Try this :
Locate the files on disk which are involved in table B (table + indexes) looking at the system catalogs
Look at the size of the files. Is the index severely bloated ? REINDEX ? DROP/Recreate the index ?
Load them into the ram cache (just cat files | wc -b several times until it's almost instantaneous)
Retry your query and your COPY
I know it's stupid... but it's a lot faster to load an index in the cache by plainly reading the file rather than accessing it randomly.
(even though, with this number of rows, it should not be THAT slow !)
---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
